Question

我知道每个人都认为单元测试应该是单一的。但是如果你读了这本书，你会发现有建立测试套件的空间。

第7章组织测试 PHPUnit的目标之一（参见第2章）是测试应该是可组合的：我们希望能够一起运行任意数量或组合的测试，例如，整个＆gt;的所有测试。项目，或作为项目一部分的组件的所有类的测试，或者只是单个类的测试。

示例7.2：使用XML配置编写测试套件

<phpunit>
  <testsuites>
    <testsuite name="Object_Freezer">
      <file>Tests/Freezer/HashGenerator/NonRecursiveSHA1Test.php</file>
      <file>Tests/Freezer/IdGenerator/UUIDTest.php</file>
      <file>Tests/Freezer/UtilTest.php</file>
      <file>Tests/FreezerTest.php</file>
      <file>Tests/Freezer/StorageTest.php</file>
      <file>Tests/Freezer/Storage/CouchDB/WithLazyLoadTest.php</file>
      <file>Tests/Freezer/Storage/CouchDB/WithoutLazyLoadTest.php</file>
    </testsuite>
  </testsuites>
</phpunit>

如果添加测试依赖项的功能：

测试依赖性

单元测试主要是作为一种良好实践编写的，可帮助开发人员识别和修复错误，重新编写代码并作为被测软件单元的文档。为了实现这些好处，理想情况下，单元测试应涵盖程序中的所有可能路径。一个单元测试通常涵盖一个功能或方法中的一个特定路径。然而，测试方法不是封装的独立实体。测试方法之间通常存在隐式依赖关系，隐藏在测试的实现方案中。

您可以在类中使用依赖关系，也可以在具有@depends ClassName :: Function的类之间使用依赖关系，并使用ClassName :: Function提供的数据。

例如，如果A类提供也在B和C类中使用的数据，则得到：

A {
    function a()
    {
        return $data;
    }
}
B {
    /**
    * @depends A::a
    */
    function b($data)
    {
        return $data2;
    }
}
C {
    /**
    * @depends B::b
    */
    function c($data2)
    {
    }
}

为什么这么糟糕？在你的意义上，将A :: a中的代码复制到类B :: b然后将类A :: a和B :: b中的代码复制到类C :: c是否更好？

我想在你的意义上学习最佳实践..我以前总是使用测试套件，单元测试非常适合测试独立功能，但是当你需要测试依赖于dpeendencies的整个服务时，它会更复杂一些。我应该完全放弃PHPUnit进行哪些测试，你有什么建议作为替代品？

Answer 1

我将用markus-tharkun写下讨论的记录：

PHPUnit旨在进行单元测试，这意味着：

单元测试的重点在于“单元”，这意味着您要测试独立单元而不是整个服务。如果每个小单元都有效，那么您的代码就可以运行单元测试并不意味着测试整个架构是否有意义。

正如我问他的那样，如果你正在测试一个具有依赖关系的函数，你可以向该函数注入一个Mock对象。您应该模拟该函数的所有外部依赖项，包括安全层，用户对象，数据库访问，所有内容。如果你真的不能模拟依赖，那么你使用@depends，但应该避免这种情况。

Markus建议我使用Mockery框架：https://github.com/padraic/mockery

编写测试套件

1 个答案: