问题描述
|
我阅读的一些资源..引用BDD作为对“ Bad TDD \”的响应。
行为规范与验证规范。测试与实施之间没有不适当的亲密关系
在业务开发测试人员之间使用普遍/共享的语言
术语强调“行为”胜过“测试”。因此，“按时间给出”，“上下文”，“场景”，“示例与测试套件”，“夹具”和“案例”。
现场规格
不知道我是否错过了更多的好处。
鉴于大多数用户（可能是本地现象）在规范的创建/阐述/澄清中“协作”，但对编辑/查看/执行/维护自动化版本不感兴趣（当然，他们希望所有规范都可以由软件满足）：
是否有xUnit的任何方面（例如NUnit）阻止它成为BDD的好工具？
根据规范编写是一种与工具无关的技能。
同理，无所不在的语言。只需付出努力就可以解决
请注意上述约束。假设我采用了xUnit测试命名风格，该风格与BDD Given-When-Then风格保持一致。
我获得/创建了一个使用上述命名约定从测试结果文件中生成类似的“实时文档”的工具。
有人可以在我的自定义BDD地图上标记“这里是龙” ...
解决方法
那是给你的龙。
无论您使用哪种语言，GUI的自动化仍然很困难。
用业务理解的术语来表达基于代码的DSL更加困难。
编写DSL需要花费一些时间。
然而：
当出现问题时，使用代码进行自动化往往会提供更快的反馈，并且调试起来更容易。在构建中包含xUnit也更容易。
维护基于代码的DSL更容易。
比起编写DSL，花更多的时间来弄清楚如何使用例如JBehave或Cucumber。
需要注意的是，“对不良TDD的反应”可能是指BDD的早期，那时我们是在类级别而不是系统或应用程序级别进行的。
我提供了使用NUnit和C＃中的DSL或Moq编写的场景和单位级别行为的示例。为我工作。除非有明显的好处，否则请不要使用自然语言工具。我为其中之一做出了广泛的贡献，因此，在没有偏见的前提下，有权提出此建议。
希望我能给您提供+1以上的好处，以唤出创建/阐述/澄清与编辑/查看/执行/维护之间的区别！