单元测试-不能从理论到实践

首先,问问自己“为什么为我的真实代码编写单元测试很困难?”也许答案是你的真实代码做得太多了。如果您有一个代码模块,其中充满了“new”语句、“If”语句和“switch”语句以及巧妙的数学语句和数据库访问,那么编写一个测试将是非常痛苦的,更不用说充分地测试逻辑和数学了。但是,如果将“new”语句拉入工厂方法,就可以很容易地提供模拟对象进行测试。如果将“If”子句和“switch”语句拉入状态机模式,就不会有这么多的组合需要测试。如果删除对外部数据提供程序对象的数据库访问,则可以提供简单的测试数据来执行数学语句。现在您正在测试对象创建、状态转换和数据访问,所有这些都是与您的聪明的数学语句分开的。所有这些步骤都简化了。

当你编写代码时,问问自己“我怎样才能为这段代码编写一个单元测试?”如果答案是“很难”,你可以考虑修改你的代码以使它更容易测试。这样做的目的是使单元测试成为代码的第一个实际使用者—您正在通过编写测试来测试代码的接口。

通过改变接口使其更易于测试,您将发现自己更好地遵守了面向对象的“紧密内聚”和“松散耦合”原则。

单元测试不仅仅是测试。编写单元测试实际上可以改进您的设计。再往前走一点,你就会得到测试驱动的开发。

因此,您考虑这一点的更好方法可能是“如何将应用程序的所有工作划分为更小、更具内聚性的代码块,这些代码块只做一两件事,并使用它们来组装应用程序?”

在您将这种思维方式内化为如何思考代码之前,单元测试可能是没有意义的。

x + 3 == 8 暗示还不够,那你呢 x == y ?

单元测试也是一个很好的地方,可以让(例如)类的用户了解如何使用该类,如何避免使用它,以及在异常情况下会发生什么(如果出现问题,您的类应该以某种特定的方式做出反应,而不是简单地中断)。有点像开发人员的内置文档。

也许从一个例子中学习对你最有用。你可以看看 NerdDinner sample app 看看它能做什么样的测试。你也可以看看 MVC source code 看看它是如何测试的。