一旦你开始写自动测试，你就会想要发掘更多用途。以下是一些例子。
12-1. 敏捷文档
通常来说，在采用敏捷方法作为开发流程的项目中，如极限编程，文档很难和迅速变化的项目设计和代码同步。极限编程要求集体拥有代码，应此，每个开发人员都熟悉整个系统。如果你严格按照规定，编写的类具有自说明能力，你就可以用PHPUnit的TextDox功能根据测试来自动生成文档。这种文档给开发人员对每个类的用途描绘了一个概貌。
PHPUnit的TestDoc功能查找测试类的所有方法的名字，把它们转换成句子，如：testBalanceIsInitiallyZero( )变成“Balance is initially zero。”如果有几个测试方法名字的不同只在于前缀或数字，如testBalanceCannotBecomeNegative( ) 和 testBalanceCannotBecomeNegative2( )，转换过的句子“Balance cannot become negative”只会出现一次，其他这样的测试都会成功。
以下代码显示用PHPUnit 生成的关于银行帐号(Bank Account)类的敏捷文档，命令是：
phpunit --testdox-text BankAccountTest.txt BankAccountTest
结果显示：
BankAccount
- Balance is initially zero
- Balance cannot become negative
也可以用--testdox-html BankAccountTest.htm选项生成HTML格式的敏捷文档。
敏捷文档也用以用于为项目中的第三方包的假定条件来记录文档。当你使用一个外部包的时候，你也在冒一定的风险。外部包可能不想你预期的那样工作，或在未来版本中有微妙变化，导致你的代码不可运行。你也通过对外部包的假定条件编写测试来解决这个问题。如果你的测试成功了，你的假定条件还是有效。如果你对所有假定条件的测试都作了文档，那么，外部包的版本问题将不再是个问题：如果测试成功了，你的系统还会正常运行。
12-2．跨团队测试
当你将测试的假定条件文档化后，你就要为你的测试负责。你和包的提供者一起确定这些假设，你要记住，包的提供者对你的测试一无所知。如果你想要与包的提供者形成更密切的关系，你可以使用测试来沟通协调相关活动。
当你同意和包的供应商协调活动时, 你们可以一起写测试。 这样做，测试会显露出尽可能许多的假定。隐藏假定条件会导致合作失败。通过测试，你可以在提供的包中地将你的期望准确记入文档。当所有的测试运行完毕时，包的供应商就知道它正常运行了。
使用残根（参见本书前面的“残根”一章），你能进一步减弱和包供应商之间的耦合。供应商的工作是测试能够运行在包的真正实现上。你的工作是测试运行在自己的代码上。在你得到供应商的包的真正的实现之前，你使用残根工作。用这种方法，两个团队能够独立工作。
12-3 调试测试
当你得到一份缺陷报告时，你的第一冲动也许是赶快修复它。经验表明，这种冲动效果不好：修复此缺陷可能会导致其它缺陷。
你应该通过检查如下列表来控制冲动：
- 再次核实一下，确信你能重现缺陷。
- 发现最小范围的出现缺陷的代码。例如，输出时如果数字不正确，找到计算那个数字的对象。
- 写一个自动化的测试，如果该缺陷被修复，此测试会通过，反之会失败。
- 修复缺陷。
发现缺陷的最小可靠再现部分提供了一个发现缺陷真正原因的机会。你写的测试将会提高正确修复缺陷的机会，因为新的测试减少了当未来代码改变时取消本次修复的可能性。
前面所写的所有测试都会减少因疏忽而造成其它问题的可能性。
12-4 重构
重构是一种改进现有的代码的设计的受控技术，只有当你有一套测试套件时才能被安全的应用。否则，你也许没有注意到当你修改结构时系统崩溃了。 重构可以分解为一系列行为保留的小的改进，这种改进不会改变程序的行为。
以下情况将帮助你改进项目的代码和设计，使用单位测试验证重构的变革步奏是行为保留的，不会引入其它错误：
- 所有单位测试运行正确。
- 代码传达它的设计意图。
- 代码没有冗余。
- 代码只包含最小数量的类和方法。
--------------------------------------------------------------------------------------------------------------------
查看本文来源
京公网安备 11010802021500号