敏捷开发的蓬勃发展、遍地开花，TDD（Test Drive Development测试驱动开发）的概念已经深入软件研发从业者的心中。
TDD讲究的是：“测试在先、编码在后”。有别于以往的“先编码、后测试”的开发过程，而是在编程之前，先写测试脚本或设计测试用例。
“测试先行”，使得开发人员对所做的设计或所写的代码有足够的信心，同时也有勇气进行设计或代码的快速重构，有利于快速迭代、持续交付。
严格来说，TDD是一种开发实践。
从软件开发角度来看，TDD是很棒的！
然而，把需求分析整理，软件开发，到产品化，再到用户使用，这样整个流程来看，单纯的TDD还是有一定瑕疵的。
TDD只涉及到Developer（开发者），只能算是开发工程师个人工作方式的改变。而现代软件开发，往往都是“产品经理（或业务）、测试人员（QA）、开发人员”三者合作的成果，如果开发人员对业务需求理解的不正确，那么写出的测试用例也是错的，这个问题是TDD解决不了的。
在不脱离敏捷开发的大前提下：业务层次，也可以采用类似TDD方*。
换言之，需求分析时就确定需求（如：用户故事）的验收标准。毕竟软件最终是要给用户使用的，要满足用户需求，解决用户的痛点。否则就会变成程序员的自high！
上面的业务层次的敏捷测试，升华到方*的高度，就是验收测试驱动开发（Acceptance Test Driven Development，ATDD）。
ATDD的执行逻辑，如下图所示：
