问题标签 [atdd]

在我们的开发中，我们使用 TDD，所以我们有一些这样的测试：

我们在这里编写的测试看起来像“单元测试”。

然后我发现 specs2 提供了另一种更易于表达的语法，我对此很感兴趣：

我想用 TDD 试试，但很快我发现这种测试是“验收规范”。一个强烈的问题浮现在我的脑海：

如果我们提到“TDD”，它们是什么类型的测试？它们必须是“单元测试”吗？使用“验收规范”来推动实施是一种好习惯吗？

在进行 TDD 时，我担心测试的“诚实”。TDD 是

1. 写红色测试
2. 编写足够的代码使其变绿
3. 重构，让测试变绿

到现在为止还挺好。现在这里是一个应用上述原理的例子，这种例子在教程和现实生活中已经遇到过：

我想检查当前用户电子邮件是否显示在我的 web 应用程序的默认页面上。

1. 编写一个红色测试：“example@user.com”显示在 default_page.html 中
2. 编写足够的代码使其变为绿色：在 default_page.html 中硬编码“example@user.com”
3. 通过实现 get_current_user()、其他一些层中的一些其他代码等进行重构，让测试变为绿色。

我对第 2 步感到“震惊”。这里出了点问题：即使没有任何实际工作，测试也是绿色的。这里有一种测试气味，这意味着也许在某些时候有人可以在不破坏测试套件的情况下破坏生产代码。

我在这里想念什么？

我们正在转向验收测试驱动的开发方法来定义功能。它似乎运行良好，但我们开始遇到测试管理问题。目前，我们使用 SharePoint/Excel 来跟踪验收测试。这是因为非技术客户、QA 和开发人员都会更新测试。问题是测试不与代码一起使用，因此它们没有与代码一起分支/版本化，而且都是非常手动的。我们正在研究完整的测试用例管理软件（例如，Zephyr、TestRail 等），但这感觉有点沉重，最终测试数据仍然无法与代码一起使用。

是否有一个对非开发人员友好的测试管理应用程序，但以一种可以与 git 一起使用的方式存储数据？试图将测试与代码放在一起是一件愚蠢的事情吗？

谢谢，埃里克

ATDD 的基本周期是在我们编写验收测试之后，我们编写该验收测试的 TDD 测试。但我的问题是，您如何指定哪些单元测试与哪个验收测试相关？是否有可能通过我们已经完成的 ATDD 和 TDD 或其他一些技术的功能？

使用 SpecFlow，我们调用了 API 服务层，然后与持久层对话。我们的大多数场景都很好地使用 API 将数据库设置为不同的状态，但是有一些场景无法通过 API 进入数据库，因为它们是故障状态。

我们想我们可以创建一个与 SpecFlow 解决方案对话的层，这反过来又将数据库“捏造”到该状态，这样我们就可以调用 API 层来检查我们是否得到了预期的响应。但是，就 BDD 而言，这是否正确？我对 BDD 的理解与 ATDD 非常相似，您可以在其中测试主要的快乐路径和异常路径，并且应该对细粒度的东西进行单元测试。

如果你不能通过 API 做某事，难道不应该在你的 BDD 场景中进行测试吗？

在 SpecFlow 中，AfterTestRun 调用未触发。我们正确地将类绑定在顶部。谷歌搜索后，我们发现这个问题发生在旧版本的 NUnit 上，并且有一个错误修复。

但是我们现在使用的是最新版本的 NUnit 2.6.4 以及最新版本的 SpecFlow 1.9.0 和 SpecFlow NUnit 1.1.1

Robot 框架和 Python 有什么区别，为什么需要安装 Python 语言才能使用 Robot 框架进行测试，在哪里运行 Robot 框架？是通过命令行吗？

我有两个黄瓜功能（DeleteAccountingYear.feature 和 AddAccountingYear.feature）。我该怎么做才能使第二个功能（AddAccountingYear.feature）在第一个功能（AddAccountingYear.feature）之前运行。

我想知道，BDD 是否只在验收测试级别工作？如果不是，它是否也适用于单元测试级别？BDD 对单元测试有什么建议吗？

谢谢你

在我们的新项目中，我想尝试使用 Gherkin 语法与我们的客户一起创建规范，然后将其用作 BDD/TDD 的基础。

在我看来，我不清楚如何处理这样一种情况，例如，客户说当某个事件发生时， UI 元素应该是某种颜色。Gherkin 规范是否应该尝试在then步骤中捕捉颜色变化？这是否意味着我们的测试（例如，在 Jasmine 中）应该检查 UI 元素的颜色而不是产生 UI 元素变化的变量的值？