xUnit 框架和 BDD 可以一起工作吗？

Question

我读过的一些资源.. 将 BDD 称为对“糟糕的 TDD”的回应。

• 行为规范与验证。测试和实现之间没有不适当的密切关系
• 在业务开发测试人员之间使用普遍/共享的语言
• 术语强调“行为”而不是“测试”。因此，给定何时、背景、场景、示例与测试套件、装置和案例。
• 实时规范

不确定我是否错过了更多好处..请参与。

鉴于大多数用户（可能是本地现象）在规范的创建/详细说明/澄清中进行“协作”，但没有对编辑/查看/执行/维护自动化版本感兴趣（当然他们希望软件满足所有规格）：

xUnit（例如 NUnit）是否有任何方面阻止它从存在BDD 的好工具？

• 根据规范进行编写是一项与工具无关的技能。
• 无处不在的语言也是如此。只需要努力才能将其取出，
• 请注意上述限制。假设我采用与 BDD Give-When-Then 风格一致的 xUnit 测试命名风格。
• 我获取/创建一个工具，它使用上述命名约定从测试结果文件生成类似的“实时文档”。

有人可以在我定制的 BDD 地图上标记“Here be Dragons”吗？

Answer 1

那么，这是给你的龙。

1. 无论使用什么语言，GUI 的自动化仍然很困难。
2. 用业务可以理解的术语来表达基于代码的 DSL 更加困难。
3. 编写 DSL 需要一点时间。

然而：

1. 在代码中进行自动化往往会在出现问题时提供更快的反馈，并且更容易调试。将 xUnit 包含在您的构建中也更容易。
2. 维护基于代码的 DSL 更容易。
3. 弄清楚如何使用 JBehave 或 Cucumber 比编写 DSL 花费的时间要长得多。

需要注意的是，“对不良 TDD 的反应”可能指的是 BDD 的早期，当时我们在类级别而不是在系统或应用程序级别进行操作。

我提供了场景和单元级行为，使用 NUnit 和 C# 中的 DSL 或 Moq 编写。对我有用。除非有明显的好处，否则不要选择自然语言工具。我对其中一项做出了广泛的贡献，因此我有权在不带偏见的情况下提出这一建议。

我希望我能为您提供+1以上的建议，以指出创建/阐述/澄清和编辑/查看/执行/维护之间的区别！