TDD 幫助工程師的開發，但在軟體的生命週期中，不是只有工程師一個角色單打獨鬥。

一個軟體的成功有賴於整個團隊，內部可能包含了PM、QA 測試人員...等等，外部則有客戶與(潛在)使用者。

如果工程師開發出來的軟體成果，並不符合客戶或市場需求，那即使開發過程再好也不會帶來成功。

因此在 TDD 之後，衍生出了新的名詞：ATDD 與 BDD。

Acceptance Testing 驗收測試

軟體開發的測試階段，其中一環叫做 驗收測試，客戶對開發的系統進行驗收，決定是否已達可接受的規格、品質等等。

客戶會用接近真實的情況去操作系統，確認目前的系統符合他們的需求。

ATDD 驗收測試驅動開發

ATDD (Acceptance test-driven development)，則是基於驗收測試去延伸了 TDD。

原本的 TDD 是從單元測試開始進行，ATDD 則是從軟體需求的角度開始，要求先寫驗收測試，先定義軟體要開發的內容、要達到的品質等。

驗收測試的書寫方式，通常是非軟體工程師也能閱讀的文件，可以是可執行的自動化測試，但也可以不是，這點與 TDD 不太相同。

ATDD 的目的在於讓工程師與團隊其他角色，能夠互助合作，並對產品需求達成共識，互相了解要完成什麼內容。

ATDD 的步驟：

1. 討論需求
2. 訂定驗收測試
3. 才開始根據規格寫軟體

BDD 行為驅動開發

繼 ATDD 之後，BDD (Behavior-driven development) 出現了。

BDD 其實跟 ATDD 相當接近，目的都是要產出符合需求的產品，就我目前看來，BDD 就像是 ATDD 的細節實作版本。

行為 (Behavior) 代表的是產品一個個的功能或操作方式，定義了產品應該要如何運作，同時這個「行為」會轉換成可執行的測試，這與 TDD 的概念相近。

有軟體套件能夠輔助 BDD，利用自然語言 (e.g. 英文、中文) 來編寫行為，能作為工程師可執行的驗收測試，且 PM、測試人員、業務等也能看懂這份自然語言所寫的規格，幫助了需求的溝通。

與 TDD 的關係

我認為 ATDD、BDD 與 TDD 的本質其實是相同的設計思維，先從要做什麼開始思考，接著是如何驗證，最後才是寫內容達成驗證。

最初的 TDD 從單元測試出發，而 ATDD 與 BDD 則是從需求面切入，基於 TDD 擴展了測試的層面，讓 TDD 的應用更加寬廣。

參考資料

1. Ian Sommerville - Software Engineering (10th Edition)
2. Acceptance Test Driven Development (ATDD)
3. Behavior Driven Development (BDD)