由外而内 TDD：我应该检查失败的验收测试吗？答案

【问题标题】：Outside-In TDD: Should I check in failing acceptance tests?由外而内 TDD：我应该检查失败的验收测试吗？
【发布时间】：2016-02-01 19:33:10
【问题描述】：

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

【问题讨论】：

【解决方案1】：

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

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

如果您担心丢失进度，或者希望将更改暂时存储为搁置集，这样您的更改就会在服务器上，并且如果您无法继续工作，其他开发人员也可以使用这些更改该功能，但同样，团队有一个工作构建，其他开发人员可以从该构建分支进行其他更改，或者可以将他们已完成的功能集成到其中。

我不会说得这么强烈，但这几乎可以概括 -

43. 仅在准备好后共享代码。永远不要签入尚未为其他人准备好的代码。故意签入未编译或未通过的代码它的单元测试应该被认为是犯罪项目的行为疏忽。
_{Practices of an Agile Developer 作者：Venkat Subramaniam 和 Andy Hunt。}

【讨论】：

很好的答案！这是（在某种程度上）使用功能分支的原因之一，您仍然可以推送代码并且该分支不会通过 CI，但没关系（取决于您团队中的协议）。
谢谢。您所说的“搁置集”是指 Augusto 提到的功能分支吗？
不，不是。在某些 VCS 中，例如TFS，您可以将更改“搁置”到服务器上，因此在本地 PC 崩溃的情况下它们是安全的，但不会影响任何 CI 构建。我认为它在 SVN 上称为“修补”，在 git 上称为“隐藏”。功能分支是远离主代码（通常称为主线、主干）的东西，团队不会（通过协议）对其应用相同的质量控制，那么团队只会担心在合并时将 CI 传递到主干。使用这种方法，我倾向于发现合并到 main 更难，因为代码是根据不同的质量规则开发的。
@Augusto 我有时可以看到好处，但我似乎很少处理只有一个开发人员的分支。 :-)

【解决方案2】：

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

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

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

如果您的测试框架没有任何此类功能，您可以随时在提交之前注释掉正在进行的测试。我通常不会将进行中的测试推送到 master，但它们在进行中的功能分支上很好。

【讨论】：