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