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

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

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

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

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倡導大家都用簡潔的自然語言描述系統行為的理念，恰好彌補了測試用例（即系統行為）的準確性。（不管以上理念是否先進，切忌盲從和濫用）