作为验证工具来说，单元测试是必要的，但是不够充分。单元测试用来验证系统的小的组成单元应该按照所期望的方式工作，但是它们没有验证系统作为一个整体时工作的正确性。单元测试是用来验证系统中个别机制的白盒测试（white-box tests）。验收测试是用来验证系统满足客户需求的黑盒测试（black-box tests）。

　　验收测试由不了解系统内部机制的人编写。客户可以直接或者和一些技术人员（可能是QA人员）一起来编写验收测试。验收测试是程序，因此是可以运行的。然而，通常使用专为应用程序的客户创建的脚本语言来编写验收测试。

　　验收测试是关于一项特性（feature）的终的文档。一旦客户编写完成了验证一项特性的验收测试，程序员可以阅读那些验收测试来真正地理解这项特性。所以，正如单元测试作为可编译、运行的有关系统内部结构的文档那样，验收测试是有关系统特性的可编译、执行的文档。

　　此外，首先编写验收测试的行为对于系统的构架方面具有深远的影响。为了使系统具有可测试性，必须要在很高的系统构架层面对系统进行解耦合。例如，为了使验 收测试无需通过用户界面（UI）能够获得对于业务规则的访问，必须要以满足这个目的的方式来解除用户界面和业务规则之间的耦合。

　　在项目迭代的初期，会受到用手工的方式进行验收测试的诱惑。但是，这样做使得在迭代的初期丧失了由自动化验收测试的需要带来的对系统进行解耦合的促进力， 所以是不明智的。当在早开始迭代时，如果非常清楚地知道必须要自动化验收测试，会做出非常不同的系统构架方面的权衡。并且，正如单元测试可以促使你在 小的方面做出优良的设计决策一样，验收测试可以促使你在大的方面做出优良的系统构架决策。

　　创建一个验收测试框架（framework）看起来是件困难的任务。然而，如果仅仅创建框架中对单个迭代包含的特性进行验收测试所需要的那部分，会发现并不困难。你还会发现所花费的努力是值得的。