如果我们和客户一起着手用例开发，用客户的话说，我们已经完成了难的部分。投入额外的精力让这些用例可以运行(通过把它们自动化)从而预防缺陷是值得的，而不要在有了缺陷后再去想办法找出它们。

　　Shore很快用一个例子继续印证了他的观点，那是他和他的团队在不使用自动化验收测试的情况下来“消除缺陷”。在这里，Shore澄清到，他并不是建议抛弃自动化验收测试，而是要用某些东西取代它，继而他描述了他眼中的“某些东西”。实质上，Shore勾勒出的方法正是当下极限编程实践的一个很棒的、严谨的应用(尽管如此，这篇文章还是非常值得一读，值得收藏)。

　　在对Jim两篇文章的回应中，Ron Jeffries参与了整个讨论过程。在诸多其它观点中，Jeffries始终像Adzic和Dinwiddie一样，认为不该遗忘自动化：

　　Jim一直坚持说他觉得测试不自动化没什么问题，而且即使客户不理解也没事。我觉得客户不理解没关系——尽管我倾向于客户能理解，如果成本很低的话。测试不要自动化的理念我却不能苟同。我担忧的是，如果测试不能自动化，回归变得门户大开、不可控制了。

　　此时，测试什么时候该自动化，什么时候不用，如果没自动化，其它测试通常要怎样才算做到位，成了要关心的问题。当然，没必要把每个用例都跑一遍来确保代码工作正常。但可能还是要跑一些。

　　...

　　我的结论是，显然Jim的团队所做的事情是可行的，而且他们做的所有XP的实践都很不错。如果其它团队也能将这些实践运用得那么好，他们可能得到类似的结果。

　　而我认为：自动化那些故事的测试用例，是预防缺陷在后续故事中出现的简单、有效的方法。

　　所以，每个人都重新强调了让业务人员和开发人员一起讨论用例依然是必不可少的一项。但至于自动化那些用例，Shore、Rainsberger和Marick认为也许不需要。其它人却说需要。

　　确实是一个有趣的讨论。你说呢?