行為驅動開發

維基百科,自由的百科全書

行為驅動開發(英語:Behavior-driven development,縮寫BDD)是一種敏捷軟件開發的技術,它鼓勵軟件項目中的開發者、QA和非技術人員或商業參與者之間的協作。BDD最初是由Dan North在2003年命名[1],它包括驗收測試和客戶測試驅動等的極限編程的實踐,作為對測試驅動開發的回應。在過去數年裏,它得到了很大的發展[2]

2009年,在倫敦發表的「敏捷規格,BDD和極限測試交流」[3]中,Dan North對BDD給出了如下定義:

BDD是第二代的、由外及內的、基於拉(pull)的、多方利益相關者的(stakeholder)、多種可擴展的、高自動化的敏捷方法。它描述了一個交互循環,可以具有帶有良好定義的輸出(即工作中交付的結果):已測試過的軟件。

BDD的重點是通過與利益相關者的討論取得對預期的軟件行為的清醒認識。它通過用自然語言書寫非程式設計師可讀的測試用例擴展了測試驅動開發方法。行為驅動開發人員使用混合了領域中統一的語言的母語語言來描述他們的代碼的目的。這讓開發者得以把精力集中在代碼應該怎麼寫,而不是技術細節上,而且也最大程度的減少了將代碼編寫者的技術語言與商業客戶、用戶、利益相關者、項目管理者等的領域語言之間來回翻譯的代價。

Dan North創造了首個BDD框架:JBehave[1];之後是Ruby語言的基於故事的RBehave[4],後來被納入了RSpec項目[5]。他還與大衛赫利姆斯基、Aslak Hellesøy及其他人開發了RSpec,並一起編寫了《The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends》。RSpec中第一個基於故事的框架,後來被主要由Aslak Hellesøy開發的Cucumber頁面存檔備份,存於互聯網檔案館)取代。

2008 年,參與了圍繞BDD進行的首輪討論的克里斯馬茨,提出了特性注入(Feature Injection)[6]的想法,使BDD可以覆蓋分析空間並提供從初期的展望到編碼和發佈的整個軟件生命周期過程的改造。

BDD 實踐[編輯]

BDD的做法包括:

  • 確立不同利益相關者要實現的遠景目標
  • 使用特性注入方法繪製出達到這些目標所需要的特性
  • 通過由外及內的軟件開發方法,把涉及到的利益相關者融入到實現的過程中
  • 使用例子來描述應用程式的行為或代碼的每個單元
  • 通過自動運行這些例子,提供快速反饋,進行回歸測試
  • 使用「應當(should)」來描述軟件的行為,以幫助闡明代碼的職責,以及回答對該軟件的功能性的質疑
  • 使用「確保(ensure)」來描述軟件的職責,以把代碼本身的效用與其他單元(element)代碼帶來的邊際效用中區分出來。
  • 使用mock作為還未編寫的相關代碼模塊的替身

特性注入[編輯]

一個公司可能有多個會帶來商業利益的不同願景,通常包括盈利、省錢或保護錢。一旦某個願景被開發小組確定為當前條件下的最佳願景,他們將需要更多的幫助來成功實現這個遠景。

然後確定該願景的主要利益相關者,會帶入其他的利益相關者。每個相關者要定義為了實現該願景他們需要完成的目標。例如,法務部門可能要求某些監管要得到滿足。市場營銷負責人可能要參加將使用該軟件的用戶的社區。安全專家需要確保該軟件不會受到SQL注入的攻擊。

通過這些目標,會定義出要實現這些目標所需要的大概的題目(theme)或者特性集合。例如,「允許用戶排序貢獻值」或「交易審計」。

從這些主題,可以得到用戶功能以及用戶界面的第一批細節。

由外及內[編輯]

BDD是由商業價值[7]--在應用開發中自然增長的商業利益--所驅動的。要認清這個利益的唯一方式,是通過用戶接口(通常--但並不總是--圖形界面,GUI)理解應用程式。

同樣,每一段代碼,從用戶界面開始,可以視作它使用的其他模塊代碼的利益相關者。每個代碼單元(element)通過與其他單元合作,提供部分行為,從而實現整個應用程式的行為。

參見[編輯]

引用[編輯]

外部連結[編輯]