编写需求并自动生成验收测试（有时候称作测试驱动需求，故事驱动开发，以及──要看你问的是谁── 行为驱动开发），在这方面已经有了零星的成功案例。然而社区中只有很少数的人这样用过。一些思想领袖公开声称这么做不好，浪费精力。每个迭代开始编写的自动化验收测试真的只是纸上谈兵吗？由于很少有人采用，这种方法是否难以奏效？

　　首先，让我们解释一下自动化的验收测试是什么意思：它是指在迭代开始时编写的测试，是用可执行形式表示的需求。当它们描述的需求开发完成后，就可以作为详细的例子说明系统具有什么样的功能──也是对“我完成后，系统看上去是什么样的呢？”这个问题最好的解答。以前最常用的自动化验收测试工具是FIT和FITNesse，然而今天已经是cucumber和rspec了。

　　这种类型的测试还没有流行起来。事实上，最近有一篇讨论，题目就是FIT死了吗？ 除此之外，在敏捷2008大会上的一个采访中，Brian Marick就宣称：

　　Q：听起来有意思极了。我赞同在业务层面的测试，客户能够理解，他们也乐于看到。你还提到了一些例子。我不知道是不是因为用文字描述测试太复杂了，你说的这些例子只是为了简化吗？但是你确实提到了客户的测试，不是吗？能否多介绍一点？

　　A：我注意到一件有趣的事情，不管在哪个方面它都与单元测试驱动设计不同，比如：你设计了一个测试，通常你对问题已经非常了解。当然单元测试做的还是单元测试的事儿。但是为了使测试自动化，不需人工干预就把例子运行起来，你需要编写支持代码，通常你不会有任何这样的想法”哈！真高兴写了那些代码，我学到了不少东西“，相反，你会这样想 ”写这些代码真是烦死人了，没学到任何东西“。所以编写那些代码不会有任何收获，除了拥有测试，你不会有任何实际的好处。直到现在，也看不出来验收测试对深奥复杂的结构有什么影响，就像重构对单元测试那样。所以我的问题是创建测试能否带来价值？编写这些代码还需要投入相当大的成本，把测试自动化能得到与付出同等的价值吗？因为如果不能从中得到同样的价值，为什么不在一个白板上测试，程序员实现功能，手工检查，甚至向产品负责人手工演示，完成以后，为什么不擦掉然后忘记它？我们为什么需要把测试保存下来，然后一遍又一遍地运行它们？

　　然而，社区中许多其他的思想领袖仍然推荐使用自动化的验收测试；仅举几个例子，比如Robert C. Martin、Joshua Kerievsky和James Shore这样的大牛。

　　Christ Matts 使用一种有趣的方式来看待这个问题，即把它作为“信息到达“的问题。比如你在软件开发过程中（不一定是敏捷的）并没有提前编写验收测试。QA团队运行他们自己的测试场景，发现缺陷后，就反馈给软件开发人员。缺陷是随机发现的，所以会影响团队的开发速度，因为开发团队必须花费一定的精力来解决这些缺陷。开发过程中，类似这样的信息会随机传递给开发团队。

　　现在，我们考虑一下如果QA部门在开发开始之前就编写测试。我们就可以预测这些信息在迭代开始时就会出现。因此不确定性的因素减少了，速度也就更稳定了（随机的打断更少了），这意味着有了更高的可预测性。

　　所以，自动化的验收测试只有所谓精英分子（或者交了狗屎运的人）才能玩的转吗？是否某些内部缺陷尚未发现，导致它名不副实？或者它确实有诸多好处，只是比较困难而已，应该鼓励每个软件开发团队去亲自尝试？