BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

六种方式改进行为驱动开发

| 作者 Jan Stenberg 关注 34 他的粉丝 ,译者 谢丽 关注 11 他的粉丝 发布于 2015年8月7日. 估计阅读时间: 3 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

行为驱动开发(BDD)的做法经常与常用的推荐做法相矛盾。在分享自己的经验以及同BDD思想领袖进行讨论的过程中,Joe Colantonio阐述了他注意到的六个常见问题以及如何进行改进。

保持BDD实现独立。包含实现细节,如GUI中的按钮,会使维护更加困难。应该重点关注用户做什么,而不是怎么做。一种实现方式是,在编写场景时,保持一种声明式风格而不是一种命令式风格。Colantonio认为,团队在BDD实现中包含实现细节的一个原因是,他们试图将BDD当作一个自动化测试框架使用,而不是按照它的初衷当作协作工具。

自动化是额外收益,而不是BDD的初衷。Colantonio提到了Seb Rose,后者曾表示,同业务或客户那边的人协作失败就是一个将BDD工具当作自动化测试工具使用的反模式。2008年,Aslak Hellesøy创建了BDD工具Cucumber。他强调,Cucumber首先是一个协作工具,旨在使所有的团队成员有一个共同的认识。Cucumber特性应该在编码实现该特性之前编写。当使用BDD编写示例时,回归测试是一个副产品,测试并不是活动本身。

一切均关乎对话。在Colantonio看来,BDD的优点在于,提供了一个避免错误假设和误解的机会,使人能够在编写代码之前发现潜在的Bug。虽然他认为,对于某些团队而言,专注于对话而不是写下需求可能会成为一个新的现实,但他同时指出,转而采用BDD和敏捷的团队应该注意,不要将场景当作需求。

一个场景不是一项需求。它们有关系,但是,一个场景集合对应一项需求。Colantonio发现,将一个场景视为一项需求会导致各种各样的问题,他倾向于在同产品经理讨论的过程中创建小型示例,比如,Gojko AdzicSpecification by Example上所描述的技术。

不要把什么都当作UI测试。场景是以用户的视角编写的,但Colantonio指出,这并不是说功能一定要通过UI进行测试,应用程序UI的内部测试组件又快又稳定。今年早些时候,Konstantin Kudryashov阐述了如何将BDD同领域驱动设计(DDD)一起使用,减少面向UI的场景的数量。首先检查工作域,只增加对UI而言非常关键的场景。

实施Scrum并不等于说实施敏捷。通过实施Scrum,团队常常会认为,他们自然而然地也在实施敏捷,但Colantonio认为,这常常是不对的。在代码编写完成后编写单元测试,或者事后编写某种验收或集成测试,可能由一个单独的团队编写,在他看来,这些都表明团队没有采用一种敏捷方法。

查看英文原文:Six Ways of Improving Behaviour-Driven Development

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT