PHPUnit袖珍指南 第十二章 测试的其他用途


一旦你开始写自动测试,你就会想要发掘更多用途。以下是一些例子。

  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 重构

  重构是一种改进现有的代码的设计的受控技术,只有当你有一套测试套件时才能被安全的应用。否则,你也许没有注意到当你修改结构时系统崩溃了。 重构可以分解为一系列行为保留的小的改进,这种改进不会改变程序的行为。

  以下情况将帮助你改进项目的代码和设计,使用单位测试验证重构的变革步奏是行为保留的,不会引入其它错误:

  -     所有单位测试运行正确。

  -     代码传达它的设计意图。

  -     代码没有冗余。

  -     代码只包含最小数量的类和方法


« 
» 
快速导航

Copyright © 2016 phpStudy | 豫ICP备2021030365号-3