可执行需求、PHPUnit 和 Jenkins 策略

Question

我们在开发中使用 Jenkins 和 PHPUnit。很长一段时间以来，我都想开始在我们的团队中使用可执行需求。架构师/团队负责人/定义需求的人可以在实际代码之前编写测试。实际代码应该由另一个团队成员编写。因此，可执行需求测试在实际代码生成之前提交到存储库，Jenkins 重建项目并理所当然地失败了。并且项目一直处于失败状态，直到编写违反 XP 规则的新代码才能始终保持项目处于良好状态。

有没有什么方法可以告诉 PHPUnit 此类测试不应该在 Jenkins 下运行，而它们可以由任何开发人员轻松地在本地执行？调整 phpunit.xml 并不是很理想：对测试的本地更改更好，因为它们更容易跟踪。

我们尝试了 markTestIncomplete() 和 markTestSkipped()，但它们并没有真正满足我们的需要：可执行需求测试确实是完整的，不应该被跳过。使用这些函数会妨碍在开发中轻松执行此类测试。

在我们的例子中，最好的方法是使用 PHPUnit 选项，如 --do-not-run-requirements，由 Jenkins 执行的 PHPUnit 应该使用该选项。在开发机器上，不应使用此选项，并且实际的可执行需求测试应在开头有 @executableRequirements 元注释（仅在创建和测试实际代码后删除）。 PHPUnit 没有这样的功能的问题。

在 Jenkins 中是否有更好的方法来实现可执行需求的实现而不会出现“错误”失败？

Answer 1

使用 PHPUnit，可以过滤测试以执行。使用@group 注释对不应在一个环境中执行的测试进行注释，然后使用--exclude-group <name-of-group> 或PHPUnit 的XML 配置文件的<group> 元素或--filter <pattern> 命令行选项。这两种方法都包含在文档中。

Answer 2

很长一段时间以来，我都想在我们的 团队。我认为在实际代码之前编写测试没有任何问题。

这不是 TDD。

引用wikipedia：

首先，开发人员编写一个（最初失败的）自动化测试用例 定义期望的改进或新功能，然后生成 通过该测试的最少代码量，...

注意单数中的test case。

话虽如此，非常欢迎您定义自己的开发方法，即一位开发人员以复数形式编写测试，将它们提交给版本控制，另一位开发人员编写代码以满足测试。 p>

解决您的困境的方法是将测试提交到一个分支，而其他开发人员则在该分支中工作。一旦所有的测试都通过了，与主干合并，Jenkins 将看到全部内容并就测试是否通过给出意见。

只是不要称它为 TDD。

Answer 3

我想在没有任何基本框架的情况下编写测试在实践中不会很直接。因此，您建议的“通过测试的最少代码量”方法并不是一个坏主意。

不一定是 TDD 方法 -谁编写测试？如果有人处理需求或 QA 成员编写测试，您可能只需编写空测试（这样它们就不会失败）。这种方法将确保开发人员将涵盖其他人考虑过的所有情况。一个示例测试方法是public void testThatObjectUnderTestReturnsXWhenACondition, public void testThatObjectUnderTestReturnsZWhenBCondition。 （我喜欢长描述性的名称，这样就不会混淆我的想法，或者您可以使用 cmets 来描述您的测试）。 DEV 可以编写代码并完成测试，或者让其他人稍后完成测试。另一种表述方式是编写可执行需求。将 Cucumber/Steak/JBehave 视为可执行需求工具。

如上所述，我们需要区分您是在尝试编写可执行需求还是单元/集成/验收测试。

如果您想编写可执行需求，任何人都可以编写它，并且可以为空以防止它们失败。然后，开发人员将填写它并确保满足要求。我的意见是让 DEV 使用 TDD（实际 TDD）处理单元/集成/验收测试，而不是将编写代码的责任与他们编写的代码的适当单元/集成/验收测试分开。