BDD 工具 Cucumber 并不是一种测试工具

如果你使用 Cucumber 的目的就是为了进行自动化测试，那么其实你还可以做得更好。你可以在 Cucumber 中编写用户场景，让它表现出业务规则而不仅仅是 UI 功能。这样你就能够让业务分析师加入这个过程，在编码工作开始前编写场景。程序员们就能够按照这个清晰的规范进行编码工作了。这种方式就是行为驱动开发（BDD）。 Aslak Hellesøy 表示，他总是看到使用者对Cucumber 的错误用法和错误理解。

Hellesøy 在 2008 年时创建了 Cucumber，在头三年之内下载量就达到了 5 百万。他始终强调，Cucumber 首先是一种协作工具，它旨在让团队中的所有成员之间达成共识。Cucumber 的特性编写应当早于具体用代码实现这些特性。当你使用 BDD 方式编写实例的时候，回归测试会自然地成为一种副带的结果，但测试本身并不是这个活动的目的。

随着 Cucumber for JavaScript 项目的出现， Julien Biezemans 看到了 BDD 在 web 开发中带来的好处，但他也同时表示，Hellesøy 所提到的那种误解，即将 Cucumber 作为一种纯粹的测试工具的想法在这个项目的应用中也是屡见不鲜。此外，对于 Biezemans 来说，BDD 也是一种鼓励所有参与者进行交流的方式，他们通过编写实例的方式让工作目标变得更清晰，并减少歧义，让每个人对于他们所创建的产品达成共识。将这些交流对话所产生的场景进行自动化，只是一种可选的步骤。

Hellesøy去年曾经表示：为了充分利用Cucumber，你必须遵循某种流程，并且让软件团队中的大多数人加入其中。这个流程就是BDD，而 Gojko Adzic 之后将这一方式重新命名为实例化需求（Specification by Example）。将这个流程稍微简化一下的话，那么它主要包括这两项活动：

• 需求工作间，此时业务分析师要对需求负责，同时与程序员与测试人员一起讨论要开发的特性（这三种角色也通常称为三个好朋友），与此同时，他们共同编写软件应该如何表现的实例，把它作为 Cucumber 中的场景。
• 由外而内的开发，程序员会增量式地进行代码编写，并且使用 Cucumber 运行场景，直到特性通过测试为止。程序员通常会从最接近用户的功能开始，然后逐步接近核心领域，这也是这一活动命名的由来。

Liz Keogh 则提示，定义BDD 是一件困难的事，因为这种方法学是从其它许多方法和哲学中派生出来的，因此她发现很难划分一个明确的边界，以确定哪些方法和哲学不属于它。Keogh 转而认为，BDD 其实是一种术语，它的核心是对话、协作与场景，以及通过自动化的方式实现它们。在这个核心之外是一系列其它实践，包括Hellesøy 所提到的内容以及各种工具，包括Cucumber、 JBehave 和 SpecFlow 。Keogh 用以下这段话表示了她对 BDD 的定义：

在对话中使用实例，以表现某种行为

查看英文原文： BDD Tool Cucumber is Not a Testing Tool