敏捷雜談之TDD與BDD

　　敏捷開發有許多種方法，但不管采用任何一種，測試都是實施敏捷的基礎，及時的驗證代碼的正確性，系統功能的健全與否，及時的反饋，及時的叫停……都是保證敏捷的基礎。所以大量的快速的自動化測試，才能保證敏捷開發在快速迭代中仍然不怎么丟失軟件的質量。

　　所以，在敏捷開發里一直都有一種說法叫“代碼即文檔”，而且測試代碼也成了功能代碼的使用文檔。敏捷里強調的TDD(Test-driven developmenet, 測試驅動開發)，就主要體現了這種思想：根據設計編寫測試-> 實現設計的功能 -> 用測試代碼驗證 -> 重構實現代碼 -> 改善設計 -> 再次回到根據改善的設計編寫測試。反復循環下去，就是TDD所倡導的流程。

　　TDD的好處：1. 能驅使系統最終的實現代碼，都可以被測試代碼所覆蓋到，也即“每一行代碼都可測”。2. 測試代碼作為實現代碼的正確導向，最終演變為正確系統的行為，能讓整個開發過程更加高效。TDD的不足之處或者說還不夠完善的地方，是對設計和測試的編寫沒有一個明確的方針。作為整個循環中的向導部分，如何保證根據設計編寫的測試就是最終用戶所期望的系統行為?如果這一部分模糊了，那么后續所有環節幾乎都要受到影響。所以，再次基礎上，敏捷社區又有人提出了BDD的概念，即“行為驅動開發”。

　　BDD(Behavior-driven development)把TDD中模糊的那一部分給明確了，強調開發、測試、BA、客戶等所有項目相關人員都用自然語言來描述系統的行為。大家看到的描述一致，讀到的內容一致，于是最終測試驅動開發產出的結果也應該是最符合用戶期望的。所以在BDD的倡導下，介紹了一種簡潔的類似自然語言叫Gherkin Language。下面看一個用Gherkin Language描述系統行為的例子：

　　[plain] view plaincopyprint?

　　As a xxx [Role]

　　I want to xxx [Feature]

　　So that I can xxx[Benefit]

　　Scenario 1: create user

　　Given a admin log into the system

　　when he create a user with name 'mike'

　　then mike should be able to log into the system

　　As a xxx [Role]

　　I want to xxx [Feature]

　　So that I can xxx[Benefit]

　　Scenario 1: create user

　　Given a admin log into the system

　　when he create a user with name 'mike'

　　then mike should be able to log into the system

　　隨著BDD的出現和發展，使用大家都能輕易理解和認知的語言來描述系統的行為并創建User Story，TDD的反復循環的流程也就能更順利的進行下去了。BDD的核心價值是體現在正確的對系統行為進行設計，所以它并非一種行之有效的測試方法。它強調的是系統最終的實現與用戶期望的行為是一致的、驗證代碼實現是否符合設計目標。但是它本身并不強調對系統功能、性能以及邊界值等的健全性做保證，無法像完整的測試一樣發現系統的各種問題。

　　有種說法是BDD是TDD的進化，其實筆者看來，沒有孰優孰劣，它們的本質和目標都是一致的。只是在實施方法上，進行了不同的探討來完善整個敏捷開發的體系。如果BDD書寫的User Story或者叫測試用例，不能作為開發、測試和客戶等人共同參與和看到的一致性內容的話，那么它的價值也幾乎得不到體現。另外一點，由于BDD不能代替完整的測試，旨在描述系統的行為，所以就像Gherkin Language的例子所體現的那樣，關鍵是“簡潔”，切忌啰嗦的想把每一步操作和任何情況都說得很清楚。

　　最后總結：TDD的迭代反復驗證是敏捷開發的保障，但沒有明確如何根據設計產生測試，并保障測試用例的質量，而BDD倡導大家都用簡潔的自然語言描述系統行為的理念，恰好彌補了測試用例(即系統行為)的準確性。(不管以上理念是否先進，切忌盲從和濫用)

原文轉自：http://www.kjueaiud.com