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

Question

我读过的一些资源指的是BDD作为对'坏TDD'的回应。

• 行为与验证的规范。测试和实施之间没有不适当的亲密关系
• 业务开发测试人员之间无所不在的/共享语言的使用
• 术语强调'行为'而不是'测试'。所以给定时，然后，上下文，情景，示例与测试套件，灯具和案例。
• 直播规格

不知道如果我错过了更多的好处..请球场英寸

考虑到大多数用户（可能是局部现象）在创建/阐述“协作” /澄清规范，但都没有兴趣编辑/查看/执行/维护自动版本（当然，他们希望所有的规格由软件来满足）：

有任何方面xUnit（例如说NUnit）阻止它成为BDD的一个好工具？

• 根据规范书写是一种与工具无关的技能。
• 对于无处不在的语言也是如此。它只需要努力把它拿出来
• 注意上面提到的约束。假定我采用了与BDD Given-When-Then样式一致的xUnit测试命名样式。
• 我得到/创建一个工具，使用上述命名约定从测试结果文件生成类似的“活文档”。

有人能记住我的定制BDD地图上的“这里是龙” ......

Answer 1

这里是你的龙，然后。

1. GUI的自动化仍然是硬的，不管你在做什么语言吧。
2. 这是很难短语基于代码的DSL在业务理解的术语。
3. 编写DSL需要一点时间。

但是：

1. 做代码自动化倾向于提供更快的反馈，当事情出错，而且它更容易调试。在构建中包含xUnit也更容易。
2. 维护基于代码的DSL更容易。
3. 研究如何使用JBehave或Cucumber比编写DSL要花费更长的时间。

作为一个说明，“反应不良TDD”所指的可能是BDD的初期，当我们在类级别而不是在一个系统或应用层面做到了。

我提供了使用NUnit和C＃中的DSL或Moq编写的scenarios和unit-level behavior的示例。适用于我。除非有明确的好处，否则不要选择自然语言工具。我对他们中的一位作出了广泛的贡献，所以感到有权在不影响的情况下提出这一建议。

我希望我可以给你+1以上的创建/阐述/澄清和编辑/查看/执行/维护之间的区别！