如何理解ATDD

验收测试驱动开发并不是关于我们该如何实现功能的方法，主要是在功能层面关注交付的软件是否符合使用者需求。一般接受过TDD训练的程序员通常会认为应该使用测试驱动开发来实施。

一个给定的故事通常代表了一块客户关注的功能，开发人员通常会将其拆解为一组方便开发的任务，然后开发人员会选择一些必须的工具和方法（如TDD）来完成这些任务。当完成一个任务的开发时，开发人员会继续下一个任务的开发，以此类推，直到故事完成为止，而故事的完成标准则由故事的验收标准定义，通过执行验收测试证明该故事已经完成。

以上过程意味着在大的迭代内有若干小的迭代，下图显示了TDD过程与验收测试驱动开发之间的过渡关系。

image

如图所示，验收测试驱动的第四步通过实现必要的代码以修复失败的验收测试，这个修复过程我们可以看做是一系列小的TDD周期，通过不断实现缺失的功能、重构代码直到验收测试通过为止。需要注意的是上图只是一个示意过程，并不代表ATDD与TDD实际的比例关系。这个过程中每个TDD的周期可能是几分钟或者几十分钟，我们可能在验收测试通过之前花费数小时甚至整天时间都在执行TDD过程。

当程序员开发一个用户故事时通常会频繁的与客户沟通功能细节，毫无疑问，某些情况下开发人员会提出新的测试场景，这时候我们需要询问客户对此的意见，如果客户认为是必要的我们就应将这些验收测试添加到我们的验收测试列表内，并在系统内增加该场景的验收测试代码。

最后，终于我们遍历了故事中确定的所有任务和所有测试，并且验收测试也顺利通过了。这时候我们可能需要写一个新的自动化验收测试，或者选择一个全新的故事来实现，我们不建议一次将一个故事的所有验收测试都自动化，建议根据开发进度逐步完成验收测试的自动化。类似如下这个过程：

image

一个迭代会包括一系列艰苦的工作，花费太多时间参加会议或者提前制定计划，然后你很快就会落后于计划，然后需要进行重新的范围界定（很可能会是另一个迭代会议）。所以我们需要确保迭代有个清晰的目标，定义良好的用户故事，并且能及时找到能解答我们问题的人（客户/产品经理），对于大多数短周期迭代我们需要花费几个小时甚至几天来编写验收测试代码，并且在必要时通过与客户合作让测试可行，最后我们通过使用我们信赖的TDD方法完成功能开发。

如上图所示的验收测试驱动开发周期：选择一个要开发的故事，为故事编写测试代码，编写代码实现故事，这个过程只是整个迭代过程中的一小部分，而一个迭代可能由几十个故事组成。为了说明单个故事的开发流程如何适应整个迭代过程，我们看一下下面这个将ATDD过程放到迭代时间轴上的示意图：

image

一个开发人员在完成当前负责的故事之前不会开始另一个新故事，这样就确保了我们在迭代过程中会持续有故事在交付，如图中所示我们可以看到几乎在迭代刚开始我们就已经有用户故事完成了，我们可以马上接下来选择一个优先级最高的故事继续开发。

ATDD常用工具

Fit
FitNeese
Selenium

更多文章请关注 @敏捷新视界