第 15 章 测试的其他用途

第 15 章 测试的其他用途

一旦习惯了编写自动化测试，你或许会发现测试的更多用途。这儿有一些例子。

敏捷文档

典型地，在使用了敏捷方法开发，例如极限编程的项目中，文档跟不上频繁改变的项目的设计和代码。极限编程要求代码的集体所有，因此所有开发者都需要了解整个系统如何运转。如果你得到了足够的训练从而将“宣告名字”用于你的测试以说明类应该做什么，你可用PHPUnit的TestDox功能基于项目的测试来为项目生成自动化文档。该文档带给开发者一个关于项目中的每个类应该做什么的概述。

PHPUnit的TestDox功能查看测试类及其所有测试方法名字，把它们从骆驼命名法变换成句子：testBalanceIsInitiallyZero()变成“Balance is initially zero”。如果一些测试方法的名字只在后缀一个或多个数字方面不同，例如testBalanceCannotBecomeNegative()和testBalanceCannotBecomeNegative2()，假如这些测试都成功，句子“Balance cannot become negative”只会出现一次。

我们来看下为BankAccount类（来自）产生的敏捷文档：

phpunit --testdox BankAccountTest
PHPUnit 3.2.10 by Sebastian Bergmann.

BankAccount
 - Balance is initially zero
 - Balance cannot become negative

另外，利用--testdox-html和--testdox-text参数，生成的敏捷文档可为HTML或无格式文本格式，并且被写入文件。

敏捷文档可被用于证明你做的关于项目中用到的外部软件包的假设。当你用到一个外部的软件包，就要被置于某些风险之中——软件包行为不符预期，而且其未来版 本会发生细微的变化，这些变化会破坏你的代码而不让你知道。你可通过每次做出假设时编写测试来处理这些风险。如果你的测试成功了，那么你的假设就是正确 的。如果你用测试证明你的所有假设，就无需担心外部软件包的未来发布版本：如果测试成功，你的系统将继续运转。

跨团队测试

当你用测试证明假设，你就拥有了自己的测试。软件包提供者——你的假设就是关于它——对你的测试一无所知。如想同软件包提供者的关系更紧密，你们可用测试进行交流和协作。

当你同软件包提供者就协作达成一致，你们就能一起编写测试。可以这样做，让测试展现出尽可能的假设。隐藏的假设是协作的终结。通过这些测试，你确切地证明了你期望的来自提供的软件包的东西。当所有的测试运行时，提供者就知道软件包完成了。

通过使用存根（见本书前面关于“模拟对象”一章），你能进一步同提供者分离：提供者的职责是让测试同软件包的真实实现一起运行。你的职责是让测试适合运行 你自己的代码。在拥有提供的软件包的真实实现之前，你使用存根对象。依据这种方式，两个团队可以独立地开发。