单元测试 – 单元测试 – 不能从理论转向实践

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

代码难以测试的一个关键原因是它包含“内部依赖关系”,例如它创建的依赖关系或对库的依赖关系.如果你的代码说“Foo theFoo = new Foo();”你不能轻易用MockFoo代替测试.但是如果你的构造函数或方法要求传入theFoo而不是构造它自己,你的测试工具可以很容易地传入MockFoo.

编写代码时,请问自己“如何为此代码编写单元测试？”如果答案是“很难”,您可以考虑更改代码以使其更容易测试.这样做是因为它使您的单元测试代码的第一个实际消费者 – 您通过编写测试来测试代码的接口.

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

单元测试不仅仅与测试有关.编写单元测试实际上改善了您的设计走得更远一点,你最终得到了测试驱动开发.

祝好运！