最近看到一個新名詞“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.
整個團隊（包括上面提到的三方成員）在開發工作開始之前，一起討論、制定每個任務（或者用戶故事）的驗收標准，並提取出一組驗收測試用例。這么做好處在於：
- 大家一起討論驗收標准和測試用例保證了對業務需求一致的理解。（這一點實際是所有開發環節中都需要關注的問題）
- 通過形成測試用例，使標准成為可執行的內容，而不是虛的指標。
國內公司一般項目開發進度很緊，大部分公司開發和測試工作由不同的人來負責，完全照搬TDD流程來開發成本過高。我更建議開發人員使用自動化測試技術編寫驗收測試用例，只要驗收測試用例能夠跑通了，就可以提交測試。