Outside-In TDD：我应该检查未通过的验收测试吗？

Question

因此，您将从失败的验收测试开始，并使用单元测试构建该功能，直到验收测试通过。但是当你通过单元测试时，你应该检查源代码控制吗？如果这样做，你是否将接受测试标记为忽略（如果是，那么在代码中或在构建服务器上）？这如何适合持续集成？

Answer 1

不，您不应该检查失败的测试，在持续集成环境中，您应该始终保持代码可释放，根据定义，失败的验收测试表明代码当前不是释放的。

  

虽然它失败了，验收测试证明了系统   尚未实现该功能;当它通过时，我们已经完成了   Steve Freeman和Nat Pryce的 _{Growing Object-Oriented Software Guided by Tests}

如果您担心会丢失进度，或者想要保留更改，请暂时将它们存储为搁置集，这样您的更改就会在服务器上，如果您无法继续工作，则可供其他开发人员使用该功能，但同样该团队有一个工作版本，另一个开发人员可以从中进行分支以进行其他更改，或者可以将其已完成的功能与其集成。

我不会强烈地说明这一点，但这几乎总结了它 -

  

43。仅在准备好时共享代码。切勿检查未准备好其他人的代码。故意检查不编译或通过的代码   其单元测试应被视为犯罪项目   过失。
  Venkat Subramaniam和Andy Hunt的 _{Practices of an Agile Developer。}

Answer 2

我不会在主分支或功能分支上将失败的验收测试推送到源控制。失败的测试会使分支机构的构建变红，这使我更难注意到我的更改可能会意外导致的其他测试失败。但是通过源代码控制分享正在进行的工作也很有帮助，因此我们需要一种方法来实现这一点，同时保持构建绿色。

我现在使用的测试框架通过提供将测试标记为未实现的方法来解决这个问题：

• 在Cucumber步骤定义中调用pending会跳过步骤和方案的其余部分并打印警告以提醒您。黄瓜的默认配置也会忽略标记为@wip的方案，尽管该机制不会产生提醒警告。
• 同样，RSpec has several ways to skip examples.

如果您的测试框架没有任何此类功能，您可以在提交之前始终注释掉正在进行的测试。我通常不会推动正在进行的测试，但他们对正在进行的功能分支很好。