行为驱动开发的反模式

  • Jan Stenberg
  • 周元昊

2016 年 10 月 9 日

话题:语言 & 开发架构文化 & 方法

正如 Kevin Smith 最近所称行为驱动开发(BDD)可以用来增进业务相关人员和软件开发者之间的沟通,然而在使用Cucumber运行自动化测试时,有一些常见的反模式需要避免。Aslak Hellesøy(Cucumber 联合创建者)、Matt WynneSteve Tooke在最近的一次讨论中对其进行了描述。

许多 Cucumber 的反模式涉及场景(scenario),也就是一段在特征细节层面对业务行为的描述。一个场景通常应该使用领域语言来描述具体业务行为。具体结构是由一个初始条件开始,紧随一个触发场景的事件,最后通过一个或一些语句来表示所期望的结果。Given-When-Then结构是一种通用的模板,如:

场景:从账户成功取钱

Given:我账户有€100

When:我申请取€20

Then:€20 被取出

在写完代码之后写场景,这是把 Cucumber 当作测试工具来使用,虽然确实有这个作用,但 Cucumber 首先是一个用来查看你对问题领域理解程度的工具,从而在写代码前能与问题领域的专业人士一起找出潜在的误解。

由领域内专家独立创建场景,这不能代表普通的认知,也缺少了开发和测试人员的参与。没有技术人员的参与,场景也将很难达到自动化。

通过 UI 测试也会产生问题。用户接口(UI)往往比业务逻辑变化更频繁,从而导致测试案例经常失败。如果并没有改变场景或业务逻辑,那么重新调试这些失败的测试案例,花费的就是不必要的精力。另一方面,通过与应用的各部分交互,再进入数据存储及后端来进行测试的速度也很慢。这样测试也可能导致缺乏对领域的理解。描述 UI 使用的主要是各领域通用的一般语言,这会导致场景的描述不能真实反映该领域所需要表达的情况。

瑞典资深 BDD 专家Thomas Sundberg引用敏捷测试金字塔主张BDD 应该被应用于所有业务有理由对具体行为产生异议的地方。他倾向于着重在集成测试上使用 BDD,并尽可能少地通过 UI 进行测试。他同时强调 Cucumber 主要不是一个测试工具,而是一个用于对系统工作方式产生共同理解的工具。

保留噪音场景,如查看空银行账户,这会使文档的相关部分模糊不清。虽然噪音场景的逻辑是理所当然的,但还需要在第一次运行测试时将它们覆盖到。Hellesøy 他们的建议是一段时间后删除它们,或至少改述成更有用的场景。

过度使用场景提纲会使测试变慢。有了场景提纲,可以使用模板添加新场景,这能很方便地增加大量场景。建议使用场景提纲时避免通过 UI 或其他较慢的方式进行测试。

其他论及的反模式包括同时测试许多规则以及糟糕的场景命名,这些都会导致误解场景的目的。附带的细节过于模糊的场景,它们没有实际的价值,要么引入了过多无关细节,要么过于抽象根本没有包含任何细节。

查看英文原文:Behaviour-Driven Development Anti-Patterns


感谢夏雪对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

语言 & 开发架构文化 & 方法