\"集成测试\"真的是阴谋?

InfoQ China刊了J.B. Rainsberger的一篇文章题为

J.B. Rainsberger:“集成测试是个阴谋”

J.B.对集成测试作了定义,认为集成测试是

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

简单可以理解为集成测试是依赖于其他(多于一个)测试的测试。

J.B.为什么认为集成测试是一个因为,他的观点是:

1.开发人员认为某一缺陷只能通过集成测试发现,因此认为应该integrate everywhere,要写大量集成测试。

2.J.B.列举一个中型web app的集成测试大概包含至少1000个集成测试,开发人员容易产生抵触情绪。

3.J.B.以两个测试进行对比,一个是对象测试(我的理解是单元测试),另一个则是集成测试,对象测试花费6秒,集成测试花费1分钟,而开发人员保持1分钟屏幕关注时间是不可能的,一分钟当中开发人员的注意力分散从而导致过多开销和低效,J.B.称之为集成测试的“隐含成本”。

关于观点1,根据我的测试经历,集成测试的目标应该关注于“集成可运行”上,比如一个集成涉及BO1, BO2,那么集成测试关注的应该是BO1+BO2得到的测试结果是可信的,而且测试结果通常不涉及太多可能性测试,比如通过不同的入口来测试集成结果的准确性,这样成本的确很高,而且会跟BO1,BO2的单元测试产生重叠,这也是一些集成测试采用MOCK测试的原因。

关于观点2,如果集成测试采用我说的那种“通过不同的入口来测试集成结果的准确性”的话,的确会发生抵触情况,因为集成测试的测试周期相对较长,内聚性不强,需要耗费很多精力,比如有可能涉及很多条件分支。

关于观点3,J.B.这里是拿集成测试和单元测试做比较,固然这是一个视角,但是这个视角是否全面我认为有失偏颇,拿一个JavaWebApp作例,对Service类做测试比较容易,如果把Action看作集成测试的话,Action测试的难度要较前者高,因而往往Action的测试有可能会被忽略掉,但是问题的发生在手工调试Action这一环节,比如出现Service中出现空指针,如果对Action做测试的话,问题有可能会在测试中发现并解决,而不是在对整个app进行编译和启动、运行、打开浏览器、输入用户名、密码,手工集成测试之后才发现问题,而这一系列过程所花的时间完全不止1分钟这么短,有可能是5分钟——完全可以来JavaEye灌水了!

如果把集成测试都累积做完之后,整个app会形成一个很完整的测试体系,再通过持续化集成工具来辅助实现集成自动化,专门拉到一台测试服务器做集成,J.B.说的那个1分钟问题其实可以完全避免,因此我认为J.B.的阴谋论有些牵强。当然,集成测试必须建立在单元测试之上,这点毋庸置疑,集成测试的重点应该根据项目实情做出策略上调整,比如对集成目标、深度的制定上做修正。

相关推荐