持续集成和验收测试驱动开发答案

【问题标题】：Continuous Integration and Acceptance Test Driven Development持续集成和验收测试驱动开发
【发布时间】：2013-02-22 10:56:07
【问题描述】：

我有一个与验收测试驱动开发 (ATDD) 相关的问题。根据流程，我从验收测试（端到端测试）开始每个功能。我提交了这些测试，但它们按预期失败了。问题是我应该以某种方式区分由于功能不完整而失败的验收测试和由于某些回归而失败的验收测试。使用 ATDD 组织 CI 流程的最佳实践是什么？

【问题讨论】：

您可以使用属性标记小黄瓜夹具 - 您可以为不完整的测试设置一个属性（如果您使用基于小黄瓜的 ATDD 框架，如 SpecFlow 或 Cucumber）
没有个人经验，但我在一家软件公司工作，他们向我展示了他们是如何开发软件的。他们在 Selenium 中编写了验收测试，并在名称中使用了 sprint ID 作为惯例。这样他们就可以很容易地看到失败的测试是新的还是旧的。你是这个意思吗？（ps：问得好，回答这么少很惊讶）

【解决方案1】：

尚未实现的测试不应在 CI 中运行。 CI 测试的重点是捕捉回归。捕捉“尚未完成”的问题会导致红色构建是“正常”并被忽略的情况。这是可能的最坏结果。

有很多方法可以做到这一点，最好的方法取决于您的具体情况。最简单的方法是先编写验收测试，但在通过之前不要签入（即您实现了该功能）。

【讨论】：

好答案。至于不签入，另一种选择是签入测试，但以某种方式禁用它们。大多数 X 单元测试框架都有某种方式告诉测试框架应该忽略某个测试。
不太同意这一点。并非所有验收测试都可以在本地执行以检查它们是否通过。需要类似生产环境来运行它们。这并不总是可用的。此外，几个开发人员可能在同一个故事上工作，他们都不会看到他们在故事上的进展，验收测试可以显示的进展。
如果不能在本地运行验收测试，那是一个严重的问题！我会努力解决这个问题。
在任何情况下，总体思路仍然适用：将“进行中的测试”与“回归测试”分开。这也可以通过使用类似 CI 的单独环境或构建来实现，但其设计方式是报告“工作中”验收测试的进度。
我知道这是一个古老的（ish）问题，但我想我会抛出一些东西。在我以前的工作场所，我们有两个构建正在运行：一个构建将执行除标记为“wip”的测试之外的所有内容（工作正在进行中）。另一个只会执行标记为 wip 的测试。冲刺/迭代完成后，将删除 wip 标签，这些测试将成为标准构建的一部分，准备好捕获任何回归错误。正如 tallseth 所说，您的所有测试都应该可以在本地执行，但我们也希望在“类似生产”的环境中运行它们。此外，它可以很好地衡量进度。