ATDD和TDD的區別是什麼？

最近看到一個新名詞「ATDD」，全稱「Acceptance Test Driven Development 」，中文稱「驗收測試驅動開發」。ATDD和TDD的區別是什麼呢，查了一些資料，個人理解以下：

先介紹一下TDD，引用Wikipedia上的關於TDD的介紹：

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.

TDD只涉及到Developer（開發者），只能算我的工做方式的改變。而現代軟件開發，每每都是「產品經理（或業務）、測試人員（或QA）、開發人員」三者合做的成果，若是開發人員對業務需求理解的不正確，那麼寫出的測試用例也是錯的，這個問題是TDD解決不了的。中文Wikipedia上對於TDD缺點的描述，也把這一問題列在第一位：

ATDD又如何解決這個問題呢？《Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing》這本書的做者Elisabeth Hendrickson給出了下面的解釋：

Acceptance Test Driven Development (ATDD) is a practice in which the whole team collaboratively discusses acceptance criteria, with examples, and then distills them into a set of concrete acceptance tests before development begins. It’s the best way I know to ensure that we all have the same shared understanding of what it is we’re actually building. It’s also the best way I know to ensure we have a shared definition of Done.

整個團隊（包括上面提到的三方成員）在開發工做開始以前，一塊兒討論、制定每一個任務（或者用戶故事）的驗收標準，並提取出一組驗收測試用例。這麼作好處在於：

1. 你們一塊兒討論驗收標準和測試用例保證了對業務需求一致的理解。（這一點實際是全部開發環節中都須要關注的問題）
2. 經過造成測試用例，使標準成爲可執行的內容，而不是虛的指標。

國內公司通常項目開發進度很緊，大部分公司開發和測試工做由不一樣的人來負責，徹底照搬TDD流程來開發成本太高。我更建議開發人員使用自動化測試技術編寫驗收測試用例，只要驗收測試用例可以跑通了，就能夠提交測試。

參考：

1. Test-driven development
2. 測試驅動開發
3. BDD就是作得比較好的ATDD嗎？
4. Acceptance Test Driven Development (ATDD): an Overview
5. 驗收測試驅動開發（ATDD）
6. 【轉】TDD和ATDD的轉化？