1.5 总结
验收测试驱动开发：ATDD实例详解
在这一章里，我们看到了业务专家、开发人员和测试人员是如何协作，在会议中挖掘出软件需求并对其达成共识的。虽然开始时Tony并没有贡献太多新的想法，但是他通过把实例可视化帮助大家达成了共识。凭借Tony独特的测试领域知识，他的贡献主要集中在使用表格来抽象描述各种停车方案的实例。
在Tony拿出第一个实例表格后，大家对需求的讨论变得更有意义了。开发人员Phyllis在他们已识别出的经济停车场的实例中发现了一个bug。她还要求对6小时零1分钟的实例进行了确认。围绕这些表格化的实例，3人进行了一场从业务视角看软件预期行为的对话。
Bill也更加清晰地表达了他的想法。他可以直接查看并确认这些实例的表述是否正确。甚至对代客泊车的实例，Bill在看到Tony创建的第一个表格之前就可以说出停24小时零1分钟的费用是多少钱。在这个需求讨论会上，就在写下第一个实例的那一刻，团队的沟通取得了明显的进展。
在讨论会进行的过程中，每个人都可以贡献一己之力。在Tony用批判性的思维讨论边界情况时，Phyllis给出了她的观点。Phyllis在开始写代码之前就发现了经济停车实例中的一个bug。修正这个缺陷只用了几句话，而不是在走完整个开发流程之后。
Tony检查了Bill最初提供的需求。他从需求中提取了实例，又仔细查看了像24小时零1分钟这样的边界条件，以便立刻从Bill那里得到正确答案。假如这些问题中的某一个在这个迭代前没有被答复，那等团队意识到这个缺陷时，Bill也许会因出差在外而无法回答他们想问的问题。那时，团队可能会为了继续开发工作，会按自己的理解给出解释。可是，假如他们的解释是错的，这个问题就只能在为客户做演示时才能发现，甚至更晚—在产品部署到生产环境几个月后才被发现。
在讨论会上，作为业务专家，Bill做了所有关于这款软件的决策：哪些要保留，哪些可以删掉。当他提到代客泊车24小时零1分钟的费用是36美元时，对他来说是很明显的事，但是Tony的问题揭开了Bill的隐含假设。仰仗参与者的多元化，团队很容易对实现的方式达成一致的目标。
团队讨论出5个清理后的表格，详见表1-11至表1-15。他们很快会实现并对这些实例进行自动化。在敏捷模式下，这可能就是下一个迭代，或3个月之内的某一个迭代要做的事。既然团队成员已经对需求进行了讨论并理解了这些基本实例，那么，即使在以后的某个时间点去实现这些已达成共识的需求故事，其过程也会是清晰的。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。