1.2 行为驱动开发
行为驱动开发（Behaviour-Driven Development，BDD）1建立于测试驱动开发的基础之上，它标准化了那些优秀TDD实践者的良好习惯。优秀的TDD实践者以自外向内的方式开发软件，最初他们会编写一个失败的客户验收测试，该测试从客户的视角描述系统的行为。作为BDD实践者，我们细心编写验收测试，作为所有团队成员都能读懂的实例。我们使用这个编写实例的过程来获取业务人员的反馈，以便在开始实现软件之前，我们就知道自己是否是在编写正确的软件。在此过程中，我们会主动开发一种共享的通用语言（ubiquitous language）来描述和讨论我们开发的系统。
1.2.1 通用语言
正如Eric Evans在他的《领域驱动设计》[Eva03]一书中所描述的，很多软件项目都受过团队中领域专家和开发人员之间低质量沟通之苦：
“如果一个项目中的语言是支离破碎的，那么这个项目就面临着严重的问题。领域专家使用他们的行话，技术团队成员则拥有自己的、专门从设计角度讨论领域的语言……由于这种语言方面的分歧，领域专家描述他们的需求的时候非常模糊。开发人员努力尝试理解一个全新的领域，却只能得到模糊的结果。”
通过整个团队的自觉努力，项目涉及的所有人都能理解和使用的一款通用语言就会出现。如果整个团队在所有交谈、文档及代码中一致地使用这种语言，就不需要再花精力去翻译各自的不同方言，理解错误的概率也因此大大地降低了。
Cucumber为存在语言分歧的双方提供了可以会合的场所，从而促进了通用语言的发现和使用。Cucumber测试直接与开发人员的代码交互，同时它们又是用一种利益相关人能够理解的中间语言编写的。通过一起编写测试的方式，即协作描述（specifying collaboratively），团队成员不仅确定了下一步要实现的行为，也学会了怎样用一种大家都能理解的通用语言描述这种行为。
如果我们在开发开始之前就编写验收测试，就可以在错误的理解渗入代码之前发现并消灭它们。
1.2.2 实例
Cucumber之所以能从大量的测试工具中脱颖而出，是因为它在设计时有一点非常明确，就是确保团队中的任何人都能够很容易地阅读或编写验收测试。这符合验收测试的本质——作为一种交流和协作的工具。Cucumber测试的易读性把利益相关人吸引到协作过程中来，帮助大家探索并真正理解他们的需求。
下面是一个Cucumber验收测试的实例：
Feature: Sign up
Sign up should be quick and friendly.
Scenario: Successful sign up
New users should get a confirmation email and be greeted
personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message
Scenario: Duplicate email
Where someone tries to create an account for an email address
that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password注意测试是如何描述为特定场景下我们期望的系统行为的实例（example）的。类似的实例能够强有力地帮助人们在系统被构建之前就将其形象化，效果通常超出大家的预期。任何团队成员都能阅读这样的测试，然后说出该测试是否反映了他对系统行为的理解，这样的测试也许还会激发他们进一步的思考，从而发现其他你未曾考虑的场景。Gojko Adzic的《实例化需求》一书包含了很多这方面的案例研究，案例中涉及的团队发现了实例的优点并将其充分利用。
以这种风格编写的验收测试已经不仅仅是测试了，它们是可执行的规格说明（executable specification）。