三种测试模式预研
在测试代码放在什么位置上,及如何运行上, 经历了如下过程:
最初模式:采用google官网单测模式:Local unit tests和 Instrumented Tests。
但:组内希望与大组保持一致,即用testng,提供一个界面点击后运行用例。同时是运行在业务app内。
因此,模式a诞生
模式考虑:和开发代码写在同一目录下,以不同package区分,同时新建测试activity界面供点击运行用例,整体测试代码编进开发代码以app运行。
缺点:
(1)和业务耦合太大,业务app在打包时需要裁掉测试代码和资源,和mainfest.xml中的测试元素。开发也不建议写在一起;
(2)同时都能以命令行运行了,还要搞界面来点击运行用例,感觉多此一举;
(3)测试范围上有些减少,比如 Android层的测试,Activity内一些private的逻辑的测试,则测试不了。非要测,就会变成触发UI点击来测,就变成了UI自动化了;
(4)与google单测理念不一致,一些google提供的测试库不支持;
(5)调试不方便,每调试一次,都要打一次包,而打包耗时较久。
优点:
(1)测试代码是在真的Android环境上执行;
(2)可以直接调用业务代码和被测接口。
综上,考虑到该模式,在测试范围,业务代码耦合,CI上,均不够好,因此放弃。
希望继续保持和大组一致,诞生了模式B。
模式考虑:因为目前小组内的产品,均是AS+gradle开发环境,而且AS+gradle也是行业趋势。因此,新建module,类型为lib,测试代码写在module下,同时被业务module依赖,相当于手管插件方式。和业务代码统一打成app,真机运行。
缺点:
1.、需要先运行业务app,才能触发测试代码,如果还需要和大组有界面点击运行,仍然需要在业务代码上 增加该代码,也是有耦合,同时业务app在打包时,需要裁掉该代码;
2、因为module只能是lib,因此被测接口要反射来调用,不能直接调用;
3、调试不方便;
4、业务打包,要裁掉该module;
5、测试范围上同样有些减少,比如 Android层的测试,Activity内一些private 的逻辑的测 试,同样测试不了。
优点:
1、测试代码剥离了,和业务耦合小了点。也可以不用界面点击来运行;
2、测试运行环境为真Android环境。
综上,考虑到该模式,在测试范围,调试方便性,均不够好,因此放弃。
最终还是回归到了最初模式:Local Unit Tests和Instrumented Tests。
方案选型
在经过各模式的预研,实践,选好测试模式后,选用什么框架来测试也是个选择。
考虑的是:Robolectric。
Robolectric样例代码:
综上:
1、从Robolectric样例代码可以看出,目前Robolectric 基本是 从UI层介入,理论上可以忽略UI层,测试单一组件的逻辑,但关键的是不能测试组件的集成逻辑。
2、android层的测试也是运行在PC端的,它并不能测试业务app在真实Android环境上的表现。
因此,最终放弃了Robolectric,选择了Local Unit Tests和Instrumented Tests。
未完待续……
关注微信公众号:腾讯移动品质中心TMQ,获取更多测试干货!