xUnit框架和BDD能一起工作吗？

Question

我读过的一些资料..。请参考BDD作为对“Bad”的答复。

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

不知道我是不是错过了更多的福利。请投进去。

考虑到大多数用户(可能是本地现象)在规范的creation/elaboration/clarification中“协作”，但对editing/viewing/executing/maintaining不感兴趣，自动化版本(当然，他们希望软件能够满足所有规范)：

xUnit (例如NUnit )是否有任何方面阻止它成为BDD的好工具？

• 以规范的形式写作是一种工具无关的技能。
• 普适语言也是如此。只是需要努力才能把它弄出来
• 注意上面提到的约束。假设我采用了一种xUnit测试命名风格，它与BDD给定的时时样式保持一致。
• 我获得/创建了一个工具，该工具使用上面的命名约定从测试结果文件中生成类似的“实时文档”。

有人能在我定制的BDD地图上标上“这里是龙”吗？

Answer 1

这是给你的龙。

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

然而：

1. 在代码中进行自动化会在出错时提供更快的反馈，而且调试起来也更容易。在构建中包含xUnit也更容易。
2. 维护基于代码的DSL更容易。
3. 计算出如何使用JBehave或Cucumber比编写DSL花费的时间要长得多。

请注意，“对糟糕的TDD的反应”可能指的是BDD的早期，当时我们在类级别而不是在系统或应用程序级别这样做。

我提供了场景和单元级行为的示例，它们使用NUnit和C#中的DSL或Moq编写。为我工作。除非有明显的好处，否则不要使用自然语言工具。我对其中之一作出了广泛的贡献，所以我认为我被授权在不带偏见的情况下提出这项建议。

我希望我能给你更多的+1来指出创建/精化/澄清和编辑/查看/执行/维护之间的区别！