正如Kevin Smith 最近所称,行为驱动开发(BDD)可以用来增进业务相关人员和软件开发者之间的沟通,然而在使用 Cucumber 运行自动化测试时,有一些常见的反模式需要避免。 Aslak Hellesøy (Cucumber 联合创建者)、 Matt Wynne 和 Steve 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 )关注我们。
评论