五分鐘讓你完全瞭解TDD、ATDD、BDD&RBE

實踐測試驅動開發（TDD）

在目前比較流行的敏捷開發模式（如極限編程、Scrum方法等）中，推崇「測試驅動開發（Test Driven Development，TDD）」——測試在先、編碼在後的開發實踐。TDD有別於以往的「先編碼、後測試」的開發過程，而是在編程以前，先寫測試腳本或設計測試用例。TDD在敏捷開發模式中被稱之爲「測試優先的編程（test-first programming）」，而在IBM Rational統一過程（Rational Unified Process，RUP）中被稱爲「測試優先的設計（test-first design）」。全部這些，都在強調「測試先行」，使得開發人員對所作的設計或所寫的代碼有足夠的信心，同時也有勇氣進行設計或代碼的快速重構，有利於快速迭代、持續交付。重構的前提就是測試就緒（testing is ready），在這樣的前提下，重構的風險就很低，不然就有比較高的風險。

TDD具體實施過程，能夠看做兩個層次，如圖1所示：

 

1. 在代碼層次，在編碼以前寫測試腳本，能夠稱爲單元測試驅動開發（Unit Test Driven Development，UTDD）

2. 在業務層次，在需求分析時就肯定需求（如用戶故事）的驗收標準，即驗收測試驅動開發（Acceptance Test Driven Development，ATDD）。

 

 

圖1  TDD的兩個不一樣層次

 

先來討論UTDD，如圖2 所示。在打算添加某項新功能時，先不要急着寫程序代碼，而是將程序可能會碰到的特定條件、邊界值、上下文等想清楚，爲待編寫（類或方法）的代碼先寫好測試腳本。而後，利用集成開發環境或相應的測試工具來執行這段測試用例，結果天然是經過不了（失敗）。利用沒有經過測試的錯誤信息反饋，瞭解到代碼沒有經過測試用例的緣由，有針對性的逐步地添加代碼。爲了要使該測試用例經過，就要補充、修改代碼，直到代碼符合測試用例的要求，得到經過。測試用例所有執行成功，說明新添加的功能經過了單元測試，能夠進入下一個環節。這樣的流程也適合代碼修改或重構，真正執行時，也不會嚴格按照這樣的流程去作，但最基本要求是：先寫好測試腳本（代碼），再寫產品代碼並經過測試。按照UTDD作法，不是先寫產品代碼的類，再寫測試類，而是先寫測試類，再寫產品的類。

 

 

圖2   UTDD執行的過程

 

UTDD從根本上改變了開發人員的編程態度，開發人員不能在像過去那樣隨意寫代碼，要求寫的每行代碼都是有效的代碼，寫完全部的代碼就意味着真正完成了編碼任務。而在此以前，代碼寫完了，實際上只完成了一半工做，遠沒有結束，由於單元測試還沒執行，可能會發現許多錯誤，一旦缺陷比較多，缺陷就比較難以定位與修正。UTDD在於促進開發人員思考功能特性的應用場景、異常狀況或邊界條件，寫出更完善的代碼，避免犯較多的錯誤。其次，也確保測試具備獨立性，不受實現思惟的影響，確保測試的客觀、全面。這一點，對開發人員測試本身的代碼是必要的。若是是倒過來，先寫產品代碼（即功能實如今前）再進行測試，那麼測試會受實現思惟影響。例如，咱們本身寫的文章本身檢查，有時很明顯的問題都發現不了，就是受實現思惟的影響。通常來講（多數狀況下），開發人員測試本身的代碼有兩個障礙：思惟障礙和心理障礙。心理障礙是指開發人員對本身的代碼不會窮追猛打，發現了一些缺陷，極可能會適可而止。咱們知道，實際上缺陷越多的地方越有風險，越要進行足夠的測試。最後，UTDD也確保全部代碼的可測試性，每一行代碼獲得了測試，比較完全地確保代碼的（微觀）質量。

許多研發人員不習慣UTDD這種模式，推行UTDD會遇到比較大的困難，那TDD的實施能夠移到業務層，推行ATDD，即在設計、寫代碼以前，明確系統功能特性的驗收標準，這比較容易推廣實施。例如，在敏捷開發模式中，每一個用戶故事的描述過於簡單，是不具備可測試性的。例如，開發一個在線旅遊網，能夠提供交通、酒店、門票等預約服務，有一個最基本的用戶故事：

 

 

 

像這樣的用戶故事，若是不加驗收標準，開發實現起來很容易，在數據庫某個表中刪除一條記錄，在其它關聯表上修改相應的標誌位便可。但實際的業務不會那麼簡單，說取消就取消？不須要有一個時間提早量？取消必定成功嗎？收不收相關的費用？是否須要線下處理的時間？是否須要通知用戶？經過什麼方式通知取消成功或失敗？要回答這些問題，就是要給這個用戶故事增長「驗收標準」，如：

 

• 取消前，須要提醒用戶再次確認

• 需提早24個小時取消

• 須要4個小時處理時間，才能知道取消成功與否

• 這類取消須要收取總金額10%的費用

• 無論取消成功與否，採用郵件和短信雙重通知

• 用戶過後能夠查詢取消的相關記錄

• 須要保留客戶和旅行網雙向操做記錄日誌

這樣，這個用戶故事才具備可測試性，開發人員也會清楚如何實現這個用戶故事，實現的結果和產品經理所指望的結果就不會有太大差別。

從ATDD演化出來一種具體落地的開發模式就是BDD（Behavior Driven Development，行爲驅動開發）。BDD只是將驗收標準更加明確化，能夠看做是ATDD的實例化，即列出用戶故事所可能遇到的應用場景，並且將這種應用場景的表達方式規定爲GWT格式，即：

 

BDD再往前推動一步，就是需求實例化（Requirements By Example，RBE），更加明確需求的具體表現。仍是以上面用戶故事爲例，能夠創建相似下列內容的需求實例化。

 

需求越明確，用戶、產品經理、開發與測試等之間的理解就越一致（on the same page），更不產生誤差和誤解，有利於開發和測試的工做。基於RBE，開發人員寫產品的代碼，測試人員能夠獨立寫測試的代碼，產品經理的工做也會變得輕鬆，不須要太多的解釋、不須要回答開發和測試的各類問題。

 

• 從需求角度看，BDD和需求實例化比較完全地明確需求，統一用戶、產品經理、開發與測試等認識，讓你們處在一個層面上，使研發工做更高效。

• 從測試角度看，需求即測試，產品的需求就是測試的需求，需求能夠被執行，即一步到位，將需求變爲自動化測試腳本，開發出來的功能特性隨時能夠被自動驗證。

 

TDD一改以往的破壞性測試的思惟方式，測試在先、編碼在後，更符合「缺陷預防」的思想。這樣一來，編碼的思惟方式發生了很大的變化，編寫出高質量的代碼去經過這些測試，在進行每項設計、寫每一行代碼時都要想一想用戶的真實需求、應用場景和一些例外等，確保實現的功能特性符合預期，並具備健壯性。測試，也從之前的破壞性的方法轉移到一種建設性的方法中來。在這種積極心態的影響下，開發人員的工做效率和產品的質量都會有顯著的提升，真正實現「質量是內建的（Quality is built in）」的目標。