敏捷软件开发——测试

Test-Driven Development 测试驱动开发

如果我们遵守了以下的规则进行开发，那么这就是测试驱动开发：

1. 在编写任何产品代码之前先写一个会运行失败的单元测试。
2. 编写一个单元测试，使其刚好能够运行失败或者编译失败。
3. 编写的产品代码应该刚好能够使失败的单元测试运行通过。

如果按照这种开发方式进行开发，那么我们将处于一个非常短的开发周期中。这样做的好处是，首先程序中的每一个单独的功能模块都经过测试来验证它的功能。这些测试将作为未来开发的一个强有力的后盾，它保证我们的开发没有破坏已有的功能。其次，测试先行的作法将使我们以一种调用者的角度来审视我们的程序。我们将关注模块之间的接口设计，这使得我们设计的程序是可以被方便地调用的。此外，先写测试的方法要求我们设计的程序是可测试的。对于软件设计来说，可调用和可测试是十分重要的，为了达到这个目的，软件必须要解耦。测试先行的另一个重要的作用是，这些测试可以作为一种文档。如果你想知道如何调用一个函数或者创建一个对象，测试用例将告诉你如何去做。这样的文档是可编译的可执行的。它永远是最新的，而且不会说谎。

Test Isolation 测试促使模块之间隔离

测试先行将使软件被更好的解耦，通过接口和Mock对象来解除模块与外界之间的依赖。

Serendipitous Decoupling 意外获得的解耦合

单元测试将促使我们将模块隔离，迫使我们从整个程序的结构角度来进行解耦。测试先行可以改善我们的设计。

Acceptance Tests 验收测试

尽管单元测试可以验证系统中的各个小部分可以如预期的运行，但是它无法验证整个系统的行为和预期相符。单元测试就好像是白盒测试，来验证系统的每个个体。验收测试则是黑盒测试来验证客户的需求是否被满足。

验收测试是一个功能的最终文档。一旦业务人员编写了验收测试来验证该功能是正确的，那么开发人员将可以通过这些验收测试更真实地理解这些功能。正如同单元测试是系统内部模块的可编译和可执行的文档，验收测试是整个系统功能的可编译和可执行的文档。简而言之，验收测试是真正的需求文档。

此外，编写验收测试将对整个系统架构有着深远的影响。为了使整个系统可测试，它必须在更高的层次上解耦。

Serendipitous Architecture 意外获得的架构