iT邦幫忙

DAY 23
3

30天快速上手TDD系列 第 23

[Day 23]BDD - Introduction

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

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

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

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

上一篇文章:[Day 22]ATDD - ATDD的循環
本系列文章專區
@前言
前面三篇文章,提到了在軟體開發流程的一開始,一切的起源都是源自使用者的需求,系統的存在是為了滿足使用者的需求,進而產生相關的效益。

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

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

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

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

因此,這篇文章要講的是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有被完成,程式碼也只具備測試案例/Scenario的需求,多的沒有,少的沒少。

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

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

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


上一篇
[Day 22]ATDD - ATDD的循環
下一篇
[Day 24]BDD - SpecFlow Introduction
系列文
30天快速上手TDD31

2 則留言

0
ted99tw
iT邦高手 1 級 ‧ 2012-10-31 16:33:37

有91正字標記的鐵文果真都是“圖文並茂”,讚讚讚!!!

讚讚讚讚讚

0
pajace2001
iT邦研究生 1 級 ‧ 2012-11-01 10:27:38

讚讚讚!!!文不如表、表不如圖~有圖真好!開心

我要留言

立即登入留言