正如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 ）关注我们。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论