最近看到一個新名詞“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缺點的描述，也把這一問題列在第一位：

TDD又如何解決這個問題呢？《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流程來開發成本過高。我更建議開發人員使用自動化測試技術編寫驗收測試用例，只要驗收測試用例能夠跑通了，就可以提交測試。