正如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或其他较慢的方式进行测试。
其他论及的反模式包括同时测试许多规则以及糟糕的场景命名，这些都会导致误解场景的目的。附带的细节和过于模糊的场景，它们没有实际的价值，要么引入了过多无关细节，要么过于抽象根本没有包含任何细节。
本文转自d1net（转载）
