[30天快速上手TDD][Day 23]BDD - Introduction

[30天快速上手TDD][Day 23]BDD - Introduction

前言

前面先介紹了如何透過 ATDD ,透過 user story 來定義與管理使用者需求開始,透過驗收測試案例來定義一個 user story 什麼時候可以視為完成。

然而 user story 與驗收測試案例,都是由 domain specific language 來描述。這與實際的程式碼來說,中間還有一段不小的落差。

該怎麼樣把中間的 gap 彌補起來,就是透過 BDD 的方式來進行。

本篇文章將針對 BDD 來做個簡單介紹。

 

介紹

前面三篇文章,提到了在軟體開發流程的一開始,一切的起源都是源自使用者的需求,系統的存在是為了滿足使用者的需求,進而產生相關的效益。

而我們透過 user story 來定義與管理使用者需求,透過驗收測試案例來定義一個 user story 什麼時候可以稱為完成。

使用驗收測試案例來當作「使用者需求」與「系統如何完成使用者需求」中間的橋樑,是一件很棒的事。

然而, user story 與 acceptance test cases 都是使用 domain specific language 來描述,但是開發人員卻是需要使用程式語言(這邊以 C# 為例)來完成系統,這中間的 gap 仍有一大段距離,該怎麼彌補這一段距離,以避免開發人員撰寫的系統,無法直接 match 驗收測試案例,以致於無法確切的滿足使用者需求。

如圖所示(抱歉,畫的有點醜):

ATDD convert to TDD

因此,這篇文章要講的是 BDD ( Behavior-driven development ),透過 BDD ,來當作驗收測試案例與系統之間的橋樑

 

What - 什麼是 BDD

BDD 的全名為 Behavior-driven development ,在 2003 年由 Dan North 所命名,用來作為 TDD 的輔助。

BDD 是透過 DSL ( Domain-specific language )來描述系統的行為。

透過屬於該 Domain 的表達方式,來描述系統的 Feature 與使用者的 Scenario ,並且依據這些 Scenario 產生對應的 code flow template ,接著可結合 Unit Test 的 3A 原則 ( Arrange, Act, Assert ),來驗證系統功能是否有滿足這些 Scenario 。

 

Why - 為什麼要使用 BDD

因為使用者的需求,要轉變成系統的程式碼,中間的落差相當大。

滿足需求

BDD 的效益在於,能讓使用者、測試人員與開發人員,可以用一樣的方式來描述與了解需求,並且降低將人話轉換成程式碼的成本

降低落差

最重要的目的,則是讓開發人員在開發系統時,還是可以專注在使用者的需求。

 

When - 什麼時候使用 BDD

當撰寫好驗收測試案例,建立好「可行走的骨架」,也就是系統雛形。開始準備著手開發實際的程式碼前,使用 BDD 來描述「驗收測試案例」所對應的「系統行為與腳本」

 

Who - BDD 該由誰來撰寫

筆者的建議是由開發人員主導,測試人員輔助,確定這樣的 Scenario 是否為測試人員所預期的,是否滿足了驗收測試案例。

確認完畢後,開發人員就可以直接從 code template 著手進行 TDD 。

 

Where - BDD 的腳本、程式碼該放在哪

BDD 的腳本,其實就是產生測試程式的骨架,只是是使用 DSL 來描述罷了。

而 BDD 的內容,其實就是 TDD 的測試案例,可能包含了整合測試與單元測試的範疇。

所以 BDD 的專案,可直接視為整合測試專案或單元測試專案,筆者是建議這兩者要分開,以便開發時可以迅速執行單元測試,在持續整合的 server 上,則可以執行到完整的測試程式。

 

小結

其實在頗久之前,筆者就留意到了 BDD 這個東西,當時就是 TDD, DDD, BDD 這類的專有名詞不斷出現。之前覺得很酷,透過 DSL 就可以用人話來輔助設計出程式與測試程式。

但當時覺得離現實生活還是太遙遠了,連單元測試怎麼寫都是問題, TDD 都還不知道怎麼進行,直接跳到 behavior ,實在太艱難了。

隨著經驗的累積,單元測試、整合測試與重構,總算比較能夠上手並運用在實際的專案上,卻在 TDD 上,碰到了一點難題。

TDD 不論技術面、概念面、流程面,我想都沒什麼太大問題,問題出在:

『測試案例』如何由 QA 的產出,變成測試程式的 input

一來,沒 domain 還是不行,沒 domain 會導致只是 developer 在自 high 、自爽,寫出來的程式可能有完整的測試,功能也可正常運作,卻不是需求要的 feature 。

TDD 的 test cases ,淪為只是為了測試單元功能,或是用來測試較大或重要的行為。即使,過程是 TDD,概念是 TDD ,技巧是 TDD ,但卻還是少了 『模擬測試使用此物件的行為』。

在一個禮拜天早上,突然對 Agile 的 user story 相當感興趣,不斷 survey 的過程中,突然想到了 BDD 這東西,這不就是用來結合 user story, ATDD 以及 TDD 的橋樑嗎?這個靈光一現,似乎找到了 TDD 的最後一塊拼圖。

最後一塊拼圖

以下是整個開發流程的相關環節,一環扣著一環:

  1. User Story:定義與管理使用者需求
  2. Acceptance Test Cases:定義 user story 的完成事項
  3. BDD 的 Feature 與 Scenario:描述 acceptance test cases 所對應的系統行為
  4. BDD 的 Step Template:用來放 TDD 的測試案例
  5. 進入 TDD 循環

原本的 unit test cases 與 integration test cases ,現在都由系統行為面來當作觸發點。滿足了這些系統行為,則代表滿足了 acceptance test cases ,則代表滿足了 user story ,則代表滿足了使用者需求

進而維持團隊一定的開發節奏,進度明顯可見,結果一翻兩瞪眼,只要測試都通過,就可以保證那一個 scenario 有被完成,程式碼也只具備 test cases/scenario 的需求,多的沒有,少的沒少

保持節奏

ATDD 與 BDD ,是筆者之前在用 TDD 貫穿整個開發流程中,最缺的一環。原因在於:

  1. 不知道測試案例怎麼來
  2. 測試案例怎麼符合使用者需求
  3. 怎麼降低使用者需求到系統程式碼中間的落差

下一篇文章,則介紹要使用 BDD ,我們可以透過什麼工具來實作。

對敏捷開發有興趣的朋友,可以參考我的粉絲專頁:91敏捷開發之路

對 TDD 課程有興趣的朋友,課程內容、大綱與學員心得,可以參考 skilltree 的公開課程:自動測試與 TDD 實務開發

若需要聯絡我,可以透過粉絲專頁私訊或是側欄的關於我。