BDD/TDD差別是什麼？ 手把手用 Cucumber 實作示範BDD

上一篇文章介紹了 TDD (Test-Driven Development) 開發流程，並示範了如何五步驟實戰應用。

TDD 重點回顧：

1. 先寫測試再開發。
2. 依循「紅燈／綠燈／重構」循環（Red/Green/Refactor）。
3. 優點是在初期就確保測試程式的撰寫，而且更容易在初期定義出更貼近使用方的介面。

但 TDD 所撰寫出來的測試案例是一連串程式碼，過於偏重技術人員，不利與其他非技術的專案參與者討論，例如 PM (Product Manager) 或 PO (Product Owner)。此外，也不利產生一份如下圖這樣一目瞭然、容易閱讀的測試報告：

‍

本篇將介紹 BDD (Behaviour-Driven Development) 如何補足這一哩路的不足，並延續上篇文章的範例來示範如何實戰 BDD。

 

‍

 

TDD 的不足 —— 非技術人員難以參與討論

還記得上篇文章的範例，我們示範了一個「員工報表管理系統」的範例，而且在步驟一透過使用者角度思考，在開發前就定義出更好的 API 介面嗎？

除了需求書表面要求的「撈出十年資深員工」功能，在使用者角度延伸思考到未來可能會有「撈出五年內的資淺員工」的需求，因而在開發前就定義出彈性更大的 API 介面，降低開始實作甚至產品上線後再回頭對 API 介面變動的風險。

「員工報表管理系統」是很簡單的範例，我們可以輕易判斷「撈出五年內的資淺員工」是個合理需求。但在現實專案中，當想到一個使用情境是需求規格書沒有定義到的，通常需要與 PM (Product Manager) 或 PO (Product Owner) 進行討論，確認是否符合產品走向。

想像一下，這時候如果企圖直接用以下測試案例當作討論素材，與 PM 或 PO 等非程式開發人員進行討論：

<p>CODE: https://gist.github.com/ackent/c64427656b6040409c2e5e7e34e120e4.js</p>

可以想見這樣的素材太過偏重工程師背景，對 PM 來說很難進入狀況。為了讓討論順利，工程師可能必須另外寫一份更易於理解的文件來描述情境，對工程師來說等於為同樣一件事花兩份功夫。

如果寫測試案例時就能寫得更接近人類可讀的規格，例如：

<p>CODE:https://gist.github.com/ackent/277484775b66545581e8a03445da99d7.js</p>

這兩份素材所描述的測試案例一模一樣，但後者類似規格書的形式，明顯人類可讀性好很多，即使非技術人員也能輕易理解內涵，以此為基礎建立討論。

而最重要的，這份規格書也要可以被自動化測試執行，甚至以此為基礎，產生一份一目瞭然的測試報告。

該怎麼實現這些理想？就是本篇接下來要介紹的 BDD。

什麼是 BDD (Behaviour-Driven Development) ？

BDD 的重要精神在於能更有效地發現問題、方便協作和示範 (BDD is about discovery, collaboration and examples)。

在上篇文章我們已經學到，TDD 是實作前先寫測試。而 BDD 比 TDD 更進一步，在寫測試前先寫測試規格書。這份測試規格會用更接近人類語意的自然語言來描述軟體功能和測試案例。而且這份規格不是單純的敘述文件，而是一份「可以被執行的規格」，也就是可以被轉成自動化測試。

輔助 BDD 實作的工具套件很多，本文將以 Cucumber 這套工具作為示範。

BDD 工具 Cucumber

以下快速介紹幾項使用 Cucumber 必備的重點知識。

Cucumber 簡介

Cucumber 是一個支援 BDD 的工具，支援三個重要目的：

• 能描寫明確可執行的規格書 (Specification)，具備人類語意可讀性，同時 Cucumber 也能解析。
• 能透過 Cucumber 進行自動化測試，驗證軟體是否符合規格書的描述。
• 能透過規格書，將軟體的功能行為文件化。

 

(圖片來源：Cucumber)

重要術語

Cucumber 在測試規格書有幾個重要術語，非常容易理解，分別是 Specification、Scenario、 Step，他們的關係如下：

• 在 Cucumber 裡，每一個使用情境或測試案例稱為一個 Scenario。
• 每一個 Scenario 有很多個 Step 要進行。
• 多個功能相近的 Scenario 可以被寫在同一份 Specification 檔案裡。
• 在 Cucumber 裡，一個 Specification 檔也被稱為 feature 檔。
• 一個專案有各種不同的功能模組，可以把所有的 Scenario 分成多個 Specification 檔便於管理。

Cucumber 怎麼撰寫規格書

由於 Specification 檔必須是可執行的 (Executable)，在 Cucumber 裡使用一個名叫 Gherkin 的語法結構來描述：

<p>CODE: https://gist.github.com/ackent/e182deef7ef93590ee07756a086a8492.js</p>

上面結構裡，Scenario 底下每一行，無論開頭關鍵字是 Given、When、Then，都代表一個 要進行 Step。

Gherkin 的特色是支援許多人類自然語言，團隊可以用自己喜歡的語言，例如英文、中文、日文、韓文等。以下就是一個繁體中文的例子：

 

(範例來源：自動軟體測試、TDD 與 BDD)

Step 開頭關鍵字

Gherkin 所撰寫的 Step，開頭都會帶一個關鍵字，便於理解這一個步驟的性質。

‍

BDD 實戰示範

接著就透過實戰來了解 BDD 的實際操作。我們將遵照 TDD 的開發流程，先寫測試才開發，差別在於我們將透過 BDD 的方式來撰寫測試。

步驟 1：安裝 Cucumber 與設定

Cucumber 支援非常多實作語言或平台，包含 Node.js、Java、PHP、Python、Android 等。

在 Node.js 裡，只需要透過 npm 就能輕易安裝：

$ npm install cucumber –save-dev

然後修改 package.json 的 script：

<p>CODE: https://gist.github.com/ackent/b58425e69c3a825ac51475f1a55d32d3.js</p>

並在專案根目錄的地方新增以下檔案：

<p>CODE: https://gist.github.com/ackent/0e80604747d97c25e6f3a40fb96d85c3.js</p>

步驟 2：撰寫第一個測試情境

就像 TDD 一開始是從測試案例切入，BDD 也是，不同的是 BDD 撰寫的是規格書。

我們新增一個 feature 檔，並加入第一個測試情境：

<p>CODE: https://gist.github.com/ackent/087f29465975cb8f9476e0b51e801b52.js</p>

步驟 3：實作 Step 定義

為了讓 Cucumber 能讀懂每一個 Step，我們必須定義每一個 Step 對應什麼動作內容。我們新增一個 js 檔專門定義每一個 Step 動作。

對應步驟 2 裡出現的 5 個 Step，我們新增了 5 個 Step 定義：

<p>CODE: https://gist.github.com/ackent/e6a69bccdbc0918f3c84e8a0fe226d40.js</p>

記得，我們遵循的仍舊是先寫測試再開發的流程，代表這個階段我們還沒實作 API 功能，只決定了介面：

<p>CODE: https://gist.github.com/ackent/a2a487e2d4e19ea05087aff7994d4926.js</p>

步驟 4：執行紅燈測試

執行以下指令執行測試：

$ npm test

因為還沒實作 API 內容，所以會得到驗證失敗的結果：
‍

‍

步驟 5：實作產品程式

<p>CODE: https://gist.github.com/ackent/ba113cefc370a0ad733ed688493378a6.js</p>

步驟 6：執行綠燈測試

如果產品程式沒有 bug，執行測試應該會得到綠燈。由於沒有任何驗證錯誤，Cucumber 預設直接顯示最後驗證結果。

以目前的例子來說總計有一個 Scenario 和五個 Step 通過驗證：

 

步驟 7：增加第二個測試情境

我們把另一個測試情境也加上去：

<p>CODE: https://gist.github.com/ackent/219305dea6ad9ddc3e58673c817dd3bd.js</p>

因為使用了新的 Step，所以也要定義對應的動作：

<p>CODE: https://gist.github.com/ackent/f3929a3a3f2120f890b3d93799541ecf.js</p>

如果程式實作無誤，應該一樣會看到測試通過：

 

至此我們就成功地以 BDD 方式完成了「員工報表管理系統」範例。

Cucumber 技巧補充一：增加 Step 定義的重用性 (Reusability)

如果你照著上面示範操作過一遍，應該會注意到一件事，那就是寫了很多重複性高的 Step 定義。

目前 Step 定義的 js 檔應該長這樣：

<p>CODE: https://gist.github.com/ackent/27ec7350efce6d06c0b919db743cb607.js</p>

總共定義了 5 個不同的 Then Step，但以實際內涵來說，其實只有 2 種類型的 Then Step 動作，其他都只是細節參數不同而已。

是否能用參數化的方式提高 Step 定義的重用性？

當然可以。在 Step 定義的部分，可以用大括號將我們想參數化的地方標示起來，大括號內註明資料型態。

例如原本的 5 個 Then Step 可以被精煉為以下 2 個 Then Step：

<p>CODE: https://gist.github.com/ackent/25ee71bf5bdcd49a59d8c4bc9b0b3b2d.js</p>

由於 `name` 和 `onboardDate` 我們定義為 string 型態，因此 feature 檔內的描述語句也要在對應的地方加上雙引號表示 string 型態：

<p>CODE: https://gist.github.com/ackent/6b76f98656cf719d49dfa87d6817bc4b.js</p>

如此就能減少撰寫太多重複性高的 Step 定義。

事實上 Cucumber 還有很多撰寫技巧有助於提高重用性，例如 Scenario Outline，就留給讀者自行發掘。

Cucumber 技巧補充二：產生精美測試報告

本文開頭展示了一張漂亮的測試結果報告圖片，是如何產生的呢？

Cucumber 有很多 plugin 支援產生不同格式的測試結果報表，例如 JSON、純文字、HTML、PDF 等等。這些 plugin 有些是內建，有些是第三方提供，可以根據自己的需求選用。

這裏示範一個第三方的 plugin cucumber-html-reporter，可以透過內建產生的 JSON 格式測試報告，進一步產生 HTML 格式的測試報告。

步驟 1：安裝 Plugin

$ npm install cucumber-html-reporter –save-dev

步驟 2：新增負責產生報表的 JS 檔

在專案根目錄新增以下檔案：

<p>CODE: https://gist.github.com/ackent/a2c9276e412058141361e26d65e062ab.js</p>

步驟 3：修改 package.json 的 script

增加一個 script `test-report-html`，在執行測試測試後會繼續產生 HTML 報表：

<p>CODE: https://gist.github.com/ackent/714b1f7a4f1492954dcb5708b7bf3bf1.js</p>

 

步驟 4：執行測試

執行以下語法：

$ npm run test-report-html

就會在測試執行完後產生報表，並且自動開啟瀏覽器展示測試報告：

‍

結語

連續兩篇文章簡單介紹了 TDD 和 BDD 的觀念，並用同一個範例貫穿實戰，示範了傳統開發模式、TDD 方式、BDD 方式分別如何開發。希望透過這樣實際操作和比較，有助於增加對 TDD、BDD 開發方式的了解。

快速回顧 TDD 和 BDD 的重點：

TDD：

• 先寫測試再開發。
• 依循「紅燈／綠燈／重構」循環（Red/Green/Refactor）。
• 在初期就確保測試程式的撰寫，而且容易在初期定義出更貼近使用方的介面。

BDD 基於 TDD 的基礎更進一步：

• 在寫測試前先寫測試規格書。
• 使用更接近人類語意的方式來描述測試情境。
• 這份規格書是一份「可以被執行的規格」，可以被轉成自動化測試，甚至產生報表。

當專案有寫自動化測試，就能進一步搭配 CI (Continuous Integration) 工具，例如每當有新的 commit 就自動執行測試檢查，不僅減少人工操作，更有助於即時發現程式問題。

測試寫越多越好？

測試是為了幫助專案確保系統品質，長遠來說自動化測試可以幫助工程師省下很多重複性的測試人力。但不可諱言，撰寫測試確實會瓜分工程師的精神和時間，尤其在專案時程和人力有限的情況下，如何取捨權衡測試覆蓋率、開發優先順序，是開發團隊的一大課題。我覺得這篇文章「過高的 Test Code Coverage 將摧毀一個新專案」能提供一些反思的觀點。

如同前一篇文章文末提到，專案開發永遠是一個權衡 (trade-off) 的過程，無論是任何工具或開發流程，目標都是為了「讓產品順利上線」，如果為了過度追求工具或流程的標準而花費過多精力，忽略現實性的資源限制，反而捨本逐末。不同專案有不同的時空環境和限制，沒有一定標準，開發團隊間應該有充分的討論和共識。

參考資料

• Cucumber 官網
• Behavior-driven development – Wikipedia
• 自動軟體測試、TDD 與 BDD – Yuren Ju – Medium
• Cucumber-java入门基础篇
• [30天快速上手TDD][Day 23]BDD – Introduction | In 91 – 點部落
• cucumber-html-reporter – npm
• 過高的 Test Code Coverage 將摧毀一個新專案

延伸閱讀：TDD五步驟 手把手帶你實戰 Test-Driven Development 範例

‍