分类：
2008-03-25 10:45:47
目前为止，我们只有2个用于内建的array和sizeof()函数的测试。当我们开始测试PHP提供的众多array_*()函数时，我们将需要为它们中的每一个都编写一个测试。我们可以从头开始为所有的测试编写基础设施。然而，一次性地编写一个测试基础设施并且只编写每个测试的特有部分会更好。PHPUnit就是这样的一个基础设施。
类似PHPUnit这样的框架必须解决一系列的限制，其中的一些似乎相互冲突。同时，测试应该：
如果编写测试很难学，开发者就不会去学。
如果测试不易编写，开发者就不会去写。
测试代码不应引入额外的开销（复杂性？ - 译注），以便测试本身不被旁杂干扰。
测试应该点下按钮就能运行，并且以清晰明确的格式呈现结果。
测试应该快速运行，以便能够每天运行成百上千次。
测试不应该相互影响。如果测试的运行顺序改变，测试的结果应该不变。
我们应能将任意数量的测试以任意的组合运行。这是相互独立的必然结果。
这些约束中有2个主要的冲突：
通常测试不需要程序语言的全部灵活性。许多测试工具提供它们特有的脚本语言，这些语言只含有编写测试所需特性的最小集。由此测试易于读写，因为没有干扰是你从测试内容分心。然而，学习其他程序语言和程序工具集并不方便，也会干扰思维。
如要一个测试的结果不影响其它测试，每个测试都应在运行前创建完整的运行场景（world）状态，并在结束时将它恢复为原始状态。可是，建立场景需时很久：例如连接数据库并用真实数据初始化为已知状态。
PHPUnit使用PHP作为测试语言来解决这些冲突。有时全功能的PHP对于编写短小直接的测试显得小题大做，但是另一方面PHP让我们可以利用程序员掌握的全部经验和工具。由于我们要说服心怀抵触的测试员，降低编写那些初始测试的门槛是非常重要的。
PHPUnit errs on the side of isolation over quick execution. 独立测试的价值在于它们提供高质量的反馈。你不会看到带有一连串测试失败的报告，这实际上是由测试集开头的一个测试失败弄乱了其他测试的场景引起的。这种 趋向于分离的测试鼓励带有大量简单对象的设计。每个对象都能单独被快速测试。由此得到的结果是更好的设计和更快的测试。
PHPUnit假设多数测试会成功，并且成功测试的细节不值得报告。失败的测试才值得注意和报告。除了统计运行的测试数量，大多数成功的测试无须关注。这 个假设被内建于报告类而不是PHPUnit内核中。在测试报告中，你能看到运行了多少测试，但是只有失败的测试才有明细。
测试应该有良好的粒度（划分）-只测试某个对象的某个方面。因此，首次测试失败就会中断测试运行并且PHPUnit会报告该错误。运行众多小测试很巧妙。测试具有良好的粒度会改善系统的总体设计。
使用PHPUnit测试一个对象，你只能利用对象公用接口。让测试仅仅基于公共可见性行为，使你在差劲的设计在系统中广为蔓延之前就能面对和解决困难的设计问题。
