敏捷開發的蓬勃發展、遍地開花，TDD（Test Drive Development測試驅動開發）的概念已經深入軟件研發從業者的心中。

TDD講究的是：“測試在先、編碼在后”。有別于以往的“先編碼、后測試”的開發過程，而是在編程之前，先寫測試腳本或設計測試用例。

“測試先行”，使得開發人員對所做的設計或所寫的代碼有足夠的信心，同時也有勇氣進行設計或代碼的快速重構，有利于快速迭代、持續交付。

嚴格來說，TDD是一種開發實踐。

從軟件開發角度來看，TDD是很棒的！

然而，把需求分析整理，軟件開發，到產品化，再到用戶使用，這樣整個流程來看，單純的TDD還是有一定瑕疵的。

TDD只涉及到Developer（開發者），只能算是開發工程師個人工作方式的改變。而現代軟件開發，往往都是“產品經理（或業務）、測試人員（QA）、開發人員”三者合作的成果，如果開發人員對業務需求理解的不正確，那么寫出的測試用例也是錯的，這個問題是TDD解決不了的。

在不脫離敏捷開發的大前提下：業務層次，也可以采用類似TDD方法論。

換言之，需求分析時就確定需求（如：用戶故事）的驗收標準。畢竟軟件最終是要給用戶使用的，要滿足用戶需求，解決用戶的痛點。否則就會變成程序員的自high！

上面的業務層次的敏捷測試，升華到方法論的高度，就是驗收測試驅動開發（Acceptance Test Driven Development，ATDD）。

ATDD的執行邏輯，如下圖所示：