著名的敏捷和TDD专家J.B. Rainsberger开始了一系列的文章，介绍他是如何根据自己的经验得到了这个比较有争议的结论：“集成测试是个阴谋”。

　　J.B.刚刚发布了系列的第一篇 ，说明了他所提到的“集成测试”的具体含义。

　　这里我要首先澄清一下我所说的“集成测试”的具体含义，因为在软件领域中，很多名词都有好多种不同的理解。

　　在我的理解中，集成测试表示那些测试结果（成功或失败）依赖于超过一个重要行为的实现正确性的测试。

　　我自然也希望有个更加严格的定义，不过这个定义绝大多数情况下都还不错。我的想法很简单：我不想要那些可能会因为多种多样问题而失败的测试。这些测试带来的问题要比它们能解决的还要多。

　　接下来，他继续解释了为什么开发人员会经常在最后写出了过多的集成测试。他给出了一个场景，其中，一位开发人员（或团队）发现了某个缺陷似乎只能通过集成测试来找到，因此得出了这样的结论——“最好在各处都提供集成测试”——以便找到这样的缺陷。

　　J.B.表明了他的态度，说这个结论“完全错误”，他继续向读者演示了一个相对较严格的基于数学的检验，察看针对一个中型大小Web应用程序进行集成测试所要花费的代价。通过给出这些数字（“至少10000（个测试），甚至无数多”），J.B.描述了这些测试占用了大量的项目时间，且很多团队最终会对此种做法产生抗拒。

　　随后，J.B.很快发布了系列的第二部分，《集成测试的一些隐含成本》，其中通过一个有趣的“两个测试套件的故事”给出了他的想法。在这个故事中，一个套件运行了6秒钟（假定主要由对象测试组成），而另一个花费了整整1分钟（假定更多由集成测试组成）。

　　使用那个6秒套件的开发者在点击“运行”按钮和得到结果之间几乎没有时间浪费在等待上：

　　6秒钟能做些什么呢？只能预测一下测试的结果了：要么全部通过，要么新添加的测试会失败，或者新的测试也通过了，因为在过去的10分钟之内你已经在代码上花费了很大力气。在这一小段时间之后，你就得到了运行的结果，那么就继续下面的工作吧。

　　而作为对比，那个使用1分钟套件的开发者则必须在点击“运行”按钮之后，再经历一个思想上的“断层”。这将引入很多额外的开销：

　　需要指出的是这里存在着双倍的开销。第一种开销很容易看到：我们等待测试的时间加上计算机等待我们的时间——因为很难让人在60秒钟之内全神贯注地盯着电脑，并在结束之后立即做出反应。这并不是什么大问题，真正的问题是由于失去耐心所带来的一系列效率下降。

　　……

　　在我编写某个（支持TDD测试的对象的）测试时，我很清楚我的目标，并专注于让其通过测试，随后关注如何将该对象良好地集成到系统中。这项工作存在着多次迭代，需要持续的注意力。这种关注和检查的一次次循环构造出了一种独特的节奏，并成为了开发人员保持注意力的动力。这也就是经常提及的所谓的“流”。6秒钟的测试很容易组成这个良好的循环，而1分钟的测试则会打破开发人员工作的进程。

　　与系列第一部分的关注点不同，J.B.在第二部分中给出了那些经常需要“一分钟测试”的开发人员的尴尬情况，以及他们可有的选择。在第一部分中，使用集成测试的开发者通常都只关心“最重要的百分之几测试用例”。

　　两篇文章都包含有大量的内容（文章本身以及相关评论），这里仅作出了简要总结。非常值得阅读。此外，Rainsberger的这两篇文章似乎还仅仅是这一系列文章的开始，如果感兴趣的话，也请继续关注下去。