将其放在上下文中。我喜欢TDD。我喜欢先写测试,然后用assertEquals和assertTrue等来表达我需要我的代码做什么。
但似乎每个人都在接受BDD计划。我看到很多关于rSpec、黄瓜和生菜的讨论。当我看到这些时,它们看起来过于冗长,几乎就像Cobol在他们天真的假设中一样,即不知何故编写冗长的“伪英语”使外行能够读懂形式规范。
一些关于BDD的文章让它听起来像是为那些发现TDD在实践中太难做的人准备的。我不觉得我有这个问题。或者,至少在哪里,它是由于在数据库或交互环境中进行TDD时出现的问题,而不是因为我不能制定测试或确定测试的优先级。
所以我的问题是。作为一个程序员,BDD对我有什么价值?a)在我为自己(或与其他程序员)编写的项目上下文中。b)在与非技术客户合作的背景下。
对于那些在许多项目中使用过BDD的人来说,除了TDD之外,它还为您带来了什么呢?你是否找到了一个客户、产品或项目经理,他们可以用BDD编写足够严格的测试用例,但不能像普通测试那样编写它们?
发布于 2012-03-11 02:22:50
我在一个非常简单的内部项目上测试了BDD,然后在一个复杂的项目上导出了它。
我发现主要的区别在于您在BDD中运行的测试的类型。BDD外部测试基于验收测试,它不处理类或任何内部代码,而是依赖于测试整个系统。BDD内部测试与您在TDD中所做的单元测试完全相同。
通过这种方式,您可以在两个级别上运行相同的红-绿-重构方法。
我发现外部测试对复杂的项目非常有帮助。
发布于 2012-03-11 08:45:33
回答问题(a),如果你没有任何非技术利益相关者,那么Cucumber可能不合适,但你相信你有足够的集成测试吗?单元测试通常是不够的。
发布于 2012-03-11 08:51:51
我喜欢这个视频关于测试驱动开发和业务驱动开发之间的区别的讨论:http://channel9.msdn.com/Series/mvcConf/mvcConf-2-Brandom-Satrom-BDD-in-ASPNET-MVC-using-SpecFlow-WatiN-and-WatiN-Test-Helpers (它的.NET工具,不一定是我使用的.NET工具,但概念是正确的)
通常,你可能会说它改善了你的反馈循环,通过改变它来检查你是否认为软件是按照你期望的那样实现的(使用TDD)来检查软件是否满足用户的需求(使用BDD)。
https://stackoverflow.com/questions/9648926
复制相似问题