利用依赖性非常重要！所谓的松散耦合是针对实际的应用程序体系结构，而不是针对单元测试用例.如果在函数执行中内置了逻辑依赖关系，那么利用这些依赖关系总是一个好主意.

Exploiting dependencies are extremely important! The loose coupling as referred to is for actual application architecture not for unit test cases. If there is logical dependencies built in to functional execution is is always a good idea to exploit those dependencies.

使用测试加倍适用于依赖项的SOA无法在黑框内将其映射到特定故障，并且服务不可靠.这不适用于应用程序间的类.

Using test doubling is appropriate for SOA where dependencies cannot be mapped to a particular failure within a black box AND the service is not reliable. This is not appropriate for inter application classes.

您肯定会使用这种类型的功能(如果测试类之间存在逻辑依赖性). 要从单元测试中把握的概念是它能够将缺陷隔离到特定的组件立即.

You definitely would want to use this type of functionality if there is logical dependencies between test classes. The concept to be grasped from unit testing is it's ability to isolate defects to particular components immediately.

此功能在PHPUnit v 3.7.13上可用.但是，唯一可行的方法是在包含两个TestCase类的目录上运行PHPUnit.

This functionality IS available on PHPUnit v 3.7.13. However, the only way this will work is if you run PHPUnit on a directory which contains both TestCase classes.

例如具有这种文件夹结构

For example with this folder structure

- application\dep
   |- BTest.php
   |- CTest.php

课程...

class BTest extends PHPUnit_Framework_TestCase
{
    /**
     * @depends CTest::testADomino
     */
    public function testDominoDependent()
    {
        $this->assertTrue(true);
    }
}

然后...

class CTest extends PHPUnit_Framework_TestCase
{
    public function testADomino()
    {
        $this->assertTrue(false);
    }
}

这是结果

C:\Users\Josh>C:\xampp\php\phpunit.bat "C:\xampp\htdocs\BeAgile\applications\sto
cklogger\tests\dep"
PHPUnit 3.7.13 by Sebastian Bergmann.

SF

Time: 0 seconds, Memory: 2.00Mb

There was 1 failure:

1) CTest::testADomino
Failed asserting that false is true.

C:\xampp\htdocs\BeAgile\applications\stocklogger\tests\dep\CTest.php:7

FAILURES!
Tests: 1, Assertions: 1, Failures: 1, Skipped: 1.

您可以在同一个文件中同时包含两个测试用例类，但这将是一个不良的结构.不必确保"一项测试先于另一项运行.

You could have both test case classes in the same file but that would be a poor structure. It is not necessary to "make sure" one test runs before the other.

作为一名敏捷教练，我看到大型组织中的测试经常翻倍，在大型组织中，专门的部门希望避免在其他组件进行更改而导致测试失败时发生构建失败.当然，这破坏了单元测试的全部目的，即在最终用户之前确定组件故障.

As an agile coach I see test doubling far too often in large organizations where specialized segments want to avoid having build failures when another components makes changes that causes test failure. This of course defeats the entire purpose of the unit tests which is to identify component failures before the end user does.