搜索
PHPUnit袖珍指南速查，参考SebastianBergmann本作品遵循CreativeCommonsAttributionLicense授权许可。可访问或发信至CreativeCommons,559NathanAbbottWay,Stanford,California94305,USA来查看本授权（license）。适用于PHPUnit3.2版，2008-03-15更新。前言必备条件自由，免费本书约定鸣谢1.自动化测试2.PHPUnit的目标3.安装PHPUnit4.编写PHPUnit测试数据提供者测试异常5.命令行测试启动器6.FixturessetUp()多tearDown()少变异共享Fixture7.组织测试套件套件级装配器8.测试用例扩展测试输出测试性能9.数据库测试数据集（暂无内容）平整的XML数据集（暂无内容）XML数据集（暂无内容）操作（暂无内容）数据库测试最佳实践（暂无内容）10.未完成和跳过的测试未完成的测试跳过的测试11.模拟对象自分流存根12.测试实践开发期间调试期间13.测试优先程序设计银行账户实例14.代码覆盖率分析指定覆盖的方法忽略代码块包含和排除文件15.测试的其他用途敏捷文档跨团队测试16.日志XML格式代码覆盖率（XML）JavaScript对象表示法（JSON）TestAnythingProtocol（TAP）GraphViz标记测试数据库17.软件度量（暂无内容）项目混乱检测器（暂无内容）18.框架（Skeleton）生成器注解19.PHPUnit和SeleniumSeleniumRCPHPUnit_Extensions_SeleniumTestCase20.持续集成CruiseControlApacheMaven21.PHPUnit的执行22.PHPUnitAPI概述PHPUnit_Framework_AssertPHPUnit_Framework_TestPHPUnit_Framework_TestCasePHPUnit_Framework_TestSuitePHPUnit_Framework_TestResult包结构23.扩展PHPUnit子类化PHPUnit_Framework_TestCase断言类子类化PHPUnit_Extensions_TestDecorator实现PHPUnit_Framework_Test子类化PHPUnit_Framework_TestResult实现PHPUnit_Framework_TestListener新测试运行器A.XML配置文件测试套件分组包含及排除用于代码覆盖率的文件日志PMD规则设置PHPINI和全局变量B.用于PHP4的PHPUnitC.索引D.参考书目E.版权前言“你打算何时写PHPUnit文档？”对于这个问题，长久以来，我的回答是“你不需要PHPUnit文档。只需阅读JUnit的文档或者买本关于JUnit的书籍，将用于JUnit的Java代码示例改编为用于PHPUnit的PHP代码即可。”当我向O'Reilly德国办事处的BarbaraWeiss和AlexandraFollenius谈及这些，他们鼓励我考虑是不是写本可作为PHPUnit文档的书。必备条件本书讨论的是PHPUnit，一个用于采用PHP程序设计语言进行测试驱动开发的开源框架。本版次适用于3.2版的PHPUnit。当然，大多数示例应该也可用于2.0-3.1版的PHPUnit。本书后面的“用于PHP4的PHPUnit”（附录B-译注）部分涉及了适用于PHP4的旧版PHPUnit，它们已不再积极开发。读者需要很好的理解使用PHP5进行面向对象程序设计。对于德国读者，我可以推荐我写的书，[Bergmann2005]，作为PHP5OOP的入门。一本关于此主题的英文书是AndiGutmans、StigBakken和DerickRethans的[GuBaRe2005]。自由，免费本书须在遵循CreativeCommonsAttributionLicense的情况下使用。你可在本书站点的找到它的最新版本。你可以对本书作任意修改并分发。当然，相对于发布你自己的私有版本，我更希望你将反馈和补丁发送至sb@sebastian-bergmann.de。本书约定下面是本书排版方面的一些约定：斜体字指示新的术语、URL、电邮地址、文件名、文件扩展名、路径名、目录和Unix实用程序。等宽字体指示命令、选项、开关、变量、函数、命名空间、方法、模块、参数、值、对象、文件内容或者命令输出。等宽粗体显示应由用户输入的命令或其他文本。等宽斜体显示应被用户提供的值替换的文本。你应该特别留意采用下列样式从（一般）文本中分离出来的注意点：注意这是个提示、建议或者常规注意。它含有关于在谈话题的有用的辅助信息。警告这是个警告或提醒。鸣谢我要感谢KentBeck和ErichGamma开发了JUnit，给了我编写PHPUnit的灵感。还要感谢KentBeck写了“JUnitPocketGuide”[Beck2004]，激起了我写本书的念头。感谢本书的发起者，O'Reilly的AllisonRandal、AlexandraFollenius和BarbaraWeiss。感谢AndiGutmans、ZeevSuraski和MarcusBörger在PHP5的核心，Zend引擎2方面的工作。感谢DerickRethans开发了Xdebug，这个PHP扩展让PHPUnit拥有了（分析）代码覆盖率功能。最后，感谢模拟对象系统的初始开发者JanBorsodi、协助制作代码覆盖率报表生成程序的MichaelLivelyJr.和JanKneschke，还有为Phing编写PHPUnit任务的MichielRook。第1章自动化测试再好的程序员也会犯错．程序员的好坏区别在于，好的程序员尽可能早地利用测试检测错误所在。越早测试，发现错误的机会越大，发现和修正的代价就越小。这解释了为什么在软件发布前才进行测试会有那么多问题。大多数错误都未被发现，而且修正已发现错误的代价如此之大，以至于你必须有选择地进行处理，因为根本不可能全部修复。使用PHPUnit进行测试与你曾经的做法并非完全不同。它只是在操作方式上有所不同。区别在于测试和执行成套测试，前者检查程序行为是否符合预期，后者是可运行的代码片断，它们自动测试软件各部分（单元）的正确性。这些可运行的代码片断称为单元测试。本章我们从简单的基于print的测试代码开始，到完整的自动化测试（结束）。假设要我们测试PHP内建的array。一个要测试的功能是函数sizeof()。对于新建的数组，我们期望sizeof()函数返回0。假如一个元素后，sizeof()应该返回1。范例1.1是我们要测试的（代码）。范例1.1:测试数组和sizeof()?php$fixture=array();//$fixture应该为空。$fixture[]='element';//$fixture应该含有一个元素。?检查我们是否得到预期结果的简单方法是在增加元素前后显示sizeof()的结果（见Example1.2）。如果先后得到0和1，array和sizeof()行为符合预期。范例1.2:使用print测试数组和sizeof()?php$fixture=array();printsizeof($fixture).\n;$fixture[]='element';printsizeof($fixture).\n;?01现在，我们要把需要人工解释（结果）的测试变为自动运行的测试。在范例1.3中，我们把预期值和实际值的比较写入测试代码，如果相同就输出ok。一旦看到notok消息，我们就知道有错误。范例1.3:比较预期值和实际值以测试数组和sizeof()?php$fixture=array();printsizeof($fixture)==0?ok\n:notok\n;$fixture[]='element';printsizeof($fixture)==1?ok\n:notok\n;?okok现在我们把预期值和实际值得比较提取出来，放入一个函数，它会在存在差异时扔出一个异常。（范例1.4）。这有2个好处：编写测试变得更容易，而且只在出错时产生输出。范例1.4:使用断言函数测试数组和sizeof()?php$fixture=array();assertTrue(sizeof($fixture)==0);$fixture[]='element';assertTrue(sizeof($fixture)==1);functionassertTrue($condition){if(!$condition){thrownewException('Assertionfailed.');}}?现在测试完全自动化了。相对于我们的第一版测试，该版已是自动化测试。使用自动化测试的目的是少犯错。即使有了极好的测试，你的代码仍不理想，一旦开始自动化测试，你将会发现缺陷明显减少。自动化测试确保你的代码的可信性。这种可信性使你可以在设计上做出更大胆的跨越（解构），同队友合作得更好（跨团队测试），改善同客户的关系，并且每晚安心回家，因为（事实）证明你的努力使系统比以前更好了。第2章PHPUnit的目标目前为止，我们只有2个用于内建的array和sizeof()函数的测试。当我们开始测试PHP提供的众多array_*()函数时，我们将需要为它们中的每一个都编写一个测试。我们可以从头开始为所有的测试编写基础设施。然而，一次性地编写一个测试基础设施并且只编写每个测试的特有部分会更好。PHPUnit就是这样的一个基础设施。类似PHPUnit这样的框架必须解决一系列的限制，其中的一些似乎相互冲突。同时，测试应该：（编写）易学。如果编写测试很难学，开发者就不会去学。易写。如果测试不易编写，开发者就不会去写。易读。测试代码不应引入额外的开销（复杂性？-译注），以便测试本身不被旁杂干扰。容易执行。测试应该点下按钮就能运行，并且以清晰明确的格式呈现结果。快速执行。测试应该快速运行，以便能够每天运行成百上千次。相互独立。测试不应该相互影响。如果测试的运行顺序改变，测试的结果应该不变。组合。我们应能将任意数量的测试以任意的组合运行。这是相互独立的必然结果。这些约束中有2个主要的冲突：（编写）易学VS易写。通常测试不需要程序语言的全部灵活性。许多测试工具提供它们特有的脚本语言，这些语言只含有编写测试所需特性的最小集。由此测试易于读写，因为没有干扰是你从测试内容分心。然而，学习其他程序语言和程序工具集并不方便，也会干扰思维。相互独立VS快速执行。如要一个测试的结果不影响其它测试，每个测试都应在运行前创建完整的运行场景（world）状态，并在结束时将它恢复为原始状态。可是，建立场景需时很久：例如连接数据库并用真实数据初始化为已知状态。PHPUnit使用PHP作为测试语言来解决这些冲突。有时全功能的PHP对于编写短小直接的测试显得小题大做，但是另一方面PHP让我们可以利用程序员掌握的全部经验和工具。由于我们要说服心怀抵触的测试员，降低编写那些初始测试的门槛是非常重要的。PHPUniterrsonthesideofisolationoverquickexecution.独立测试的价值在于它们提供高质量的反馈。你不会看到带有一连串测试失败的报告，这实际上是由测试集开头的一个测试失败弄乱了其他测试的场景引起的。这种趋向于分离的测试鼓励带有大量简单对象的设计。每个对象都能单独被快速测试。由此得到的结果是更好的设计和更快的测试。PHPUnit假设多数测试会成功，并且成功测试的细节不值得报告。失败的测试才值得注意和报告。除了统计运行的测试数量，大多数成功的测试无须关注。这个假设被内建于报告类而不是PHPUn