Cucumber 是一個BDD的測試框架，它從業務角度出發，使用業務相關的語言(非技術語言)，描述系統具有的行為。它更關注的是業務層面而非代碼層面的邏輯。
在這篇文章里，我將首先介紹BDD, 然后介紹Cucumber以及相關概念。
一 BDD
Behavior-Driven Development is about implementing an application by describing its behavior from the perspective of its stakeholders.
這里需要注意兩點：
1)stakeholders：軟件的使用者，受益者，通俗的說就是軟件的客戶。
2)behavior：這里的behavior，指的是從stakeholders的角度看到的軟件系統的行為。
BDD的作用：
其實BDD和agile是緊密相關的。在agile中，我們使用BDD測試作為acceptance test。也就是說，當分析出一個user story后，我們應該有一個BDD的case與之對應，作為衡量軟件是否滿足該需求的一個標準。其實，從某種程度上講，BDD就是TDD的發展，BDD出現的背景，就是開發人員在TDD時，不清楚到底該將一個什么樣的story作為自己TDD開發需要實現的目標。
而BDD簡單的回答了這個問題：讓stakeholders用一個test case告訴你，你的具體目標是什么。同時強調了，每一個開發目標都應該是系統的behavior的體現。
BDD的三原則：We sum this up using the following three principles of BDD:
Enough is enough:
Up-front planning, analysis, and design all have a diminishing return. We shouldn’t do less than we need to get started, but any more than that is wasted effort. This also applies to process automation. Have an automated build and deployment, but avoid trying to automate everything.
這一點秉承的原則：不做多余的事。
Deliver stakeholder value:
If you are doing something that isn’t either delivering value or increasing your ability to deliver value, stop doing it, and do something else instead.
這一點秉承的原則：做對客戶有價值的事。
It’s all behavior：
Whether at the code level, the application level, or beyond, we can use the same thinking and the same linguistic constructs to describe behavior at any level of granularity.
這一點秉承的原則：實現的都是有價值的行為。
二 Cucumber
Cucumber 是一個基于BDD的測試框架，它能夠幫助團隊使用業務上的語言對軟件系統的行為進行測試。同單元測試相比，Cucumber的測試更多關注的是業務級別的行為，因此非開發人員、業務專家或者客戶能夠容易的參與，從而保證軟件系統的行為切實符合業務需求。同時，通過Cucumber的測試，開發人員也能更正確、清晰的理解業務需求，保證開發出來的系統滿足客戶的期望。由于Cucumber采用幾乎近于自然語言的方式描述了軟件的行為過程，因此可以直接作為軟件的需求文檔，也可以直接作為測試或者系統驗收的標準文檔。 這種方式也淋漓盡致的體現了敏捷的思想：代碼即是最有效的文檔。
三 Cucumber的概念
Cucumber中有幾個重要的概念：
1. Feature
Feature指的是軟件系統所提供的某個功能，一般對應 User Story。在一個Cucumber 的feature文件中，主要定義了用戶如何使用軟件提供的該功能。通常我們這樣定義feature：
Feature: <description>
As a <role>
I want <feature>
So that <business value>
即作為某個角色，我想使用系統做些事情，從而得到期望的實現業務價值的結果。
在feature的定義中，通常會涉及如下幾個問題：
a) Who is using the system?
b) What are they doing?
c) Why do they care?
比如說：
Feature: Adding the numbers by calculator
As a customer,
I want to calculate the two numbers,
so that I can get the right results.
通常一個feature文件中會包括一個或者多個Scenario。
2. Scenario
Scenario描述了用戶使用軟件的場景，即在某種前提條件下，當用戶使用軟件觸發某個行為，那么應該會得到一個預期的結果。 比如說：
Scenario: Add two numbers
Given the input "2+2"
When the calculator is run
Then the output should be "4"
即當使用計算器求和時，假如給定了2+2的前提條件，那么當點擊計算時，期望的結果應該是4.
通常Scenario由一組步驟(step)組成。
3. Step
Step 描述了在完成一次同軟件交互的過程中，所需要的每個動作。
通常有三種step：
1) 給定的條件(Given)
2)觸發的行為(When)
3)期待的結果(Then)
比如上個例子中定義當完成一次計算兩數相加的行為時，需要3個步驟
Given the input "2+2" //步驟1，確定前提條件，如我希望計算的數字是2+2；
When the calculator is run //步驟2，運行計算器，并開始計算；
Then the output should be "4" //步驟3， 驗證期待的結果是4.
4. Step definition(implementations)
Step是使用業務層面的描述語言完成的，比如剛才提到的測試計算器的例子。 針對這種業務層面的描述語言，必然有對應的技術層面的實現，才能將這些業務描述語言轉變成對系統進行測試的代碼。 我們稱這種對業務語言的技術實現為step definition. 比如對上個例子的step，我們使用的實現偽代碼如下所示 ：
Given /^the input([^"]*)"$/ do |input_number|
//get the input expression by the regexp match
input = input_number
end
When /^the calculator is run$/ do
//run the calculator and trigger it to do calculation by input
result = calculator(input)
end
Then /^the output should be ([^"]*)"$/ do |expected_result|
//get the expected result by the regexp match
//verify whether the result is as we expected
result == expected_result
end
四 總結
本文介紹了BDD、Cucumber的背景, 以及Cucumber中涉及的概念(Feature, Scenario, Step, Step definition)，后續將介紹如何使用Cucumber來幫助我們測試軟件系統的行為。