Not*_*elf 127 tdd bdd unit-testing
测试驱动开发在过去几年中一直是.NET社区的风靡一时.最近,我听到了ALT.NET社区关于BDD的抱怨.它是什么？是什么让它与TDD不同？
Chr*_*yer 102
我理解BDD更多是关于规范而不是测试.它与域驱动设计相关联(你不喜欢这些*DD缩略词吗？).
它与编写用户故事的某种方式相关联,包括高级测试.Tom ten Thij的一个例子:
Story: User logging in
As a user
I want to login with my details
So that I can get access to the site
Scenario: User uses wrong password
Given a username 'jdoe'
And a password 'letmein'
When the user logs in with username and password
Then the login form should be shown again
(在他的文章中,Tom继续在Ruby中直接执行此测试规范.)
BDD的教皇是Dan North.您将在他的BDD简介文章中找到一个很好的介绍.
您将在此视频中找到BDD和TDD的比较.还有一个关于BDD的观点是Jeremy D. Miller所说的"TDD做得对"
2013年3月25日更新
上面的视频已经缺失了一段时间.这是Llewellyn Falco最近的一篇,BDD与TDD(解释).我发现他的解释清楚而且非常重要.
Juh*_*nen 17
对我来说,BDD和TDD之间的主要区别在于焦点和措辞.而言语对于传达你的意图很重要.
TDD将重点放在测试上.而且,由于"旧瀑布世界"测试在实施后出现,因此这种心态会导致错误的理解和行为.
BDD将注意力集中在行为和规范上,因此瀑布思维分散注意力.因此,BDD更容易被理解为设计实践,而不是测试实践.
小智 13
似乎有两种类型的BDD.
第一个是Dan North讨论的原始风格,它引发了xBehave风格框架的创建.对我来说,这种风格主要适用于验收测试或针对域对象的规范.
第二种风格是Dave Astels的推广,对我来说,这是TDD的一种新形式,它具有一些重要的好处.它侧重于行为而不是测试以及小型测试类,试图达到每个规范(测试)方法基本上有一行的程度.这种风格适合所有级别的测试,可以使用任何现有的单元测试框架完成,尽管更新的框架(xSpec样式)有助于将行为集中在一起而不是测试.
您还可以找到一个有用的BDD组:
http://groups.google.com/group/behaviordrivendevelopment/
小智 7
测试驱动开发是一种测试优先的软件开发方法,这意味着它需要在编写将要测试的实际代码之前编写测试代码.在Kent Beck的话中:
这里的样式是编写几行代码,然后是一个应该运行的测试,甚至更好,编写一个不会运行的测试,然后编写将使其运行的代码.
在弄清楚如何编写一小段代码之后,现在,我们希望获得即时反馈并实践"代码一点,测试一点,代码一点,测试一点".所以我们马上为它写一个测试.
因此,TDD是一种低级技术方法,程序员可以使用它来生成干净的代码.
行为驱动开发是一种基于TDD创建的方法,但演变为一个不仅仅涉及程序员和测试人员的流程,而是涉及整个团队和所有重要的利益相关者,技术和非技术.BDD从一些简单的问题开始,TDD没有很好地回答:我应该写多少测试？我应该测试什么 - 我不应该做什么？我写的哪些测试对业务或产品的整体质量实际上很重要,哪些只是我的过度工程？
如您所见,此类问题需要技术与业务之间的协作.业务利益相关者和领域专家通常可以告诉工程师哪种测试听起来有用 - 但前提是测试是处理重要业务方面的高级测试.BDD将此类业务测试称为"示例",如"告诉我此功能应如何正确运行的示例",并为低级技术检查(如数据验证或测试API集成)保留"测试"一词.重要的是,虽然测试只能由程序员和测试人员创建,但是整个交付团队可以收集和分析示例 - 设计人员,分析师等.
在一句话中,到目前为止我发现 BDD的最佳定义之一是BDD与"与领域专家进行对话并使用示例来获得对所需行为的共同理解并发现未知数."发现部分非常重要.随着交付团队收集更多示例,他们开始越来越多地了解业务领域,从而减少了他们必须处理的产品的某些方面的不确定性.随着不确定性的降低,交付团队的创造力和自主性也在增加.例如,他们现在可以开始建议他们自己的例子,由于他们缺乏技术专长,业务用户认为不可能.
现在,与业务和领域专家进行对话听起来很棒,但我们都知道这通常会在实践中结束.我以技术作为程序员开始了我的旅程.作为程序员,我们被教导编写代码算法,设计模式,抽象.或者,如果您是一名设计师,您将被教导设计 -组织信息并创建漂亮的界面.但是,当我们获得入门级工作时,我们的雇主希望我们"为客户创造价值".在这些客户中,例如......银行.但除了如何有效降低账户余额之外,我几乎无法了解银行业务.因此,我必须以某种方式将对我的期望转化为代码...如果我想提供任何价值,我将不得不在银行业务和我的技术专长之间架起一座桥梁.BDD帮助我在交付团队和领域专家之间建立稳定的流畅沟通基础上建立了这样一座桥梁.
学到更多
如果你想了解更多关于BDD的信息,我写了一本关于这个主题的书."编写出色的规范"探讨了分析需求的艺术,并将帮助您学习如何构建出色的BDD流程,并将示例用作该流程的核心部分.本书讨论了无处不在的语言,收集示例,并从示例中创建所谓的可执行规范(自动化测试),这些技术可帮助BDD团队按时和按预算提供出色的软件.
如果您有兴趣购买"写出优秀的规格",您可以使用促销代码39nicieja2 节省39% :)
我已经用BDD方法进行了一些实验,我的早熟结论是BDD非常适合用例实现,但不适用于底层细节.TDD仍然在这个水平上徘徊.
BDD也用作通信工具.目标是编写可由领域专家理解的可执行规范.