著名的敏捷和 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 的这两篇文章似乎还仅仅是这一系列文章的开始,如果感兴趣的话,也请继续关注下去。
查看原文: http://www.infoq.com/news/2009/04/jbrains-integration-test-scam “J.B. Rainsberger: “Integration Tests Are A Scam””">J.B. Rainsberger: “Integration Tests Are A Scam”
评论