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

Question

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

• 行为规范与验证。测试和实施之间没有不恰当的亲密关系
• 在业务开发测试人员之间使用普遍存在的/共享语言
• 术语强调“行为”而不是“测试”。所以当时的时间，上下文，场景，示例与测试套件，灯具和案例。
• 实时规格

不确定我是否错过了更多优惠..请投入。

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

是否存在xUnit的任何方面（比如说NUnit）会阻止它成为BDD的好工具？

• 根据规范进行编写是一种与工具无关的技能。
• 同样适用于无处不在的语言。只需要努力就可以搞定它
• 请注意上述约束。假设我采用与BDD Given-When-Then样式对齐的xUnit测试命名样式。
• 我得到/创建了一个使用上述命名约定的工具，从测试结果文件中生成类似的“实时文档”。

有人可以在我自定义的BDD地图上标记“Here be dragons”......

Answer 1

然后，这是给你的龙。

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

然而：

1. 在出现问题时进行代码自动化可以提供更快的反馈，而且调试起来更容易。在构建中包含xUnit也更容易。
2. 维护基于代码的DSL更容易。
3. 与编写DSL相比，制定如何使用JBehave或Cucumber需要更长的时间。

作为一个注释，“对坏TDD的反应”可能是指BDD的早期阶段，当时我们是在课堂级而不是系统级或应用级执行。

我提供了scenarios和unit-level behavior的示例，使用NUnit和C＃中的DSL或Moq编写。适合我。除非有明显的好处，否则不要选择自然语言工具。我已经为其中一个做出了广泛的贡献，所以我觉得有权在没有偏见的情况下提出这个建议。

我希望我能给你超过+1，以表示创作/阐述/澄清与编辑/观看/执行/维持之间的区别！