当面对一个没有任何测试代码的遗留系统时,如果要想修改其中的程序结构或是新增代码,需要谨小慎微才行,因为这是一件风险极大的事情。尤其是大规模的改动,稍有不慎便会破坏原有代码的正确性,从而引入bug,而这种bug,也许只能通过后期的集成测试才能被发现。按照经典软件工程的理论,这种bug的修改成本,往往都是代价高昂的。始终以TDD方式进行软件开发的结果便是形成一整套可运行的测试用例集。这使得我们对软件所做的后续修改有了很好的保障。因为每一项功能都有与之对应的测试用例来确保其正确性,所以任何对软件既有功能的修改或是增加都可以通过运行完整的测试用例集获得反馈,使你在第一时间得知改动后的软件质量状况。
现实中要维护文档与代码的同步往往是一件令人头疼的事情。不仅如此,一些文档时常有流于形式的倾向,没有真正起到有效沟通的目的。而敏捷方法则主张:能够正确运行的代码要比详实的文档更加重要。在敏捷团队中,文档不再是洋洋洒洒数百页,而是代之以精简的文字和务实的表达,甚至有人将代码本身也看作是“文档”。按照这样的观点,测试代码就是描述功能代码使用方法的一份天然的“文档”。测试用例为我们提供了如何调用被测类的样例代码。利用这份准确可靠,且能直接运行的特殊“文档”,我们可以从中了解到被测代码的使用细节。并且,这类“文档”不会像普通文档那样,存在与实际代码不同步的问题。因为一旦失去了同步,自动或手工运行的测试用例集便会在第一时间告知我们。
-----摘自《程序员》作者:莫映