4

自从我听说 BDD（行为驱动开发）以来，我一直想知道它是否补充了 TDD？它在 Web 开发中真的有用吗？作为一个忙碌的 .net Web 开发人员，是否值得花时间在 BDD 和 TDD 上？当我浏览它时，我发现它很有趣，但我对它对我们有什么用处感到困惑！

我遇到过这句话，但它实际上是什么意思？

尽管这些工具通常是专门为在 BDD 项目中使用而开发的，但它们可以被视为支持测试驱动开发的工具的特殊形式。这些工具用于将自动化添加到作为 BDD 中心主题的无处不在的语言中。

4

4 回答 4

4

首先，一些定义；

TDD 是测试驱动开发，顾名思义，我们生产的测试驱动我们的开发流程。它通常与 Red-Green-Refactor 循环一起描述。所以在实践中，我们编写了一个单元测试，它失败了，给我们一个红色状态，然后我们修复我们的应用程序的代码，直到我们通过测试，给我们一个绿色状态，最后我们重构我们的应用程序代码和我们的测试代码，所以我们有很好的设计。好的 TDD 通过将每个测试集中在我们要测试的类中的单个方法上并注入模拟依赖项来工作，因此我们正在测试尽可能少的代码，这会导致测试套件中的单个错误导致单个失败。

BDD 是行为驱动开发，其中行为是我们设计过程的驱动因素。当您遵循 BDD 流程时，您会与人们一起了解您的应用程序应该如何运行，它的特性是什么，并捕获它应该在其中运行的场景的一些示例。事实上，我们也可以将 BDD 视为一个循环，我们收集一个新的应用程序应该具有的功能，验证应用程序是否适用于所有场景，可能重构我们的测试，以便它们最有意义并再次重复。BDD 测试通常需要许多类协作来生成单个业务功能，因此即使错误仅触发单个故障，您仍然有大量代码来追踪负责的代码。

在这一点上你可以看到 BDD 在比 TDD 更高的层次上工作，事实上我已经看到 BDD 外循环成功地用于驱动多个组织中的 TDD 内循环，即

定义新的业务功能
 ---> 添加场景和测试：BDD Red
| -> 添加单元测试：TDD Red
| | 添加应用代码：TDD Green
| -- 重构代码：TDD 重构
| 场景通行证：BDD 绿色
 --- 重构特性和场景：BDD 重构
功能齐全

Gojko Adzic 在他的演示文稿 TDD 中更好地描述了这一点：打破常规

它如何在 Web 开发中真正有用？ BDD 在用于收集需求的过程和通过 BDD 工具自动确认您的代码库具有业务所需的所有功能方面非常有用。我发现 BDD 最适合与许多类协作的集成样式测试，而不是专注于单个方法的单元测试。

您将使用 BDD 来构建您的应用程序逻辑，并且您可以使用它来测试您的大部分网站。我个人会回避测试 UI，而是在代码隐藏中工作，使用诸如“当用户搜索 BDD”之类的语言，但是有些人使用 Selenium 并编写讨论点击和测试框的测试“当用户输入搜索文本框中的 BDD 并单击搜索按钮”。

作为 .net 中忙碌的 Web 开发人员，是否值得花时间在 BDD 和 TDD 上？

希望现在您应该能够自己回答这个问题。您需要决定将 BDD 引入您的流程中可以获得多少好处。您的收益将因团队规模和您选择的工具等因素而异。

我注意到您正在通过使用 nBehave 标记您的问题来查看 BDD 工具的纯文本规范形式。这使您能够有一个 BA 团队处理纯文本场景并将它们提交回来（尽管不要全部交给他们，您需要一些技术输入来保持场景的一致性）。其他形式的工具（例如 mSpec）以另一种方式工作，使用 C# 描述场景并生成纯文本作为构建过程的结果。我个人使用 SpecFlow，它具有 nBehave 的所有优点，但它的测试可以通过 nUnit 运行器、resharper 和您的构建服务器运行。但是，您可能希望将集成测试与单元测试分开，并报告不同级别的覆盖率。

最后

尽管这些工具通常是专门为在 BDD 项目中使用而开发的，但它们可以被视为支持测试驱动开发的工具的特殊形式。这些工具用于将自动化添加到作为 BDD 中心主题的无处不在的语言中。

这意味着 BDD 工具的工作方式与我们现有的 TDD 工具类似，并且知道如何生成或理解 Given When Then 的 BDD 语法。有关这方面的更多信息，我建议阅读https://github.com/cucumber/cucumber/wiki/Gherkin。

如果你想更多地了解 BDD 作为一个过程，那么 Liz Keogh 有很多非常好的材料，从这里开始http://lizkeogh.com/behaviour-driven-development/

（哎呀，这比我开始时想象的要长得多）

于 2013-10-02T12:16:26.643 回答
1

TDD 和 BDD 之间的主要区别在于范围。TDD 是一种开发实践，而 BDD 是一种团队方法。在 TDD 中，开发人员编写测试，而在 BDD 中，自动化规范由用户或测试人员创建（开发人员将它们连接到被测代码。）对于小型、同地、以开发人员为中心的团队，TDD 和 BDD 是有效的相同的。

在这里你的两个问题都有全面的答案。

您可以在此处找到一些 TDD 和 BDD 的代码示例

于 2013-10-02T06:14:15.347 回答
1

BDD 补充了 TDD

Cucumber（以及一般的 BDD）的想法是利益相关者协助编写场景或可执行规范。这解决了我们从哪里开始 TDD 的问题。

http://dannorth.net/introducing-bdd

于 2015-09-11T07:05:06.723 回答
1

BDD 是以正确的方式完成 TDD，Dan North 本人是一名 TDD 培训师，他发现如果我们可以将“测试”这个词替换为“行为”，它会更有帮助。

BDD 的主要原则是

  1. 从外向内工作 --> Test First 方法论，从外向内意味着编写测试来测试您与外界的接口，这意味着编写测试来测试系统的行为

  2. 无所不在的语言 --> 非技术人员和技术人员都能理解的语言，这就是 GWT(Given When Then) 格式的由来

  3. 使用示例 --> 示例是行为测试应通过的一组输入和输出。

于 2015-11-10T23:02:40.193 回答