|
本帖最后由 草帽路飞UU 于 2022-10-24 14:59 编辑
1 引言
1.1背景
随着Android应用越来越壮大,对应代码量显著增加,代码逻辑也日趋复杂,此时需要采取一定的行动去保证代码质量,减少逻辑漏洞等,于是严格地执行单元测试编写任务,将单元测试落实到平常开发
和维护任务当中去,就是很重要的一环,不可忽视。
然而,很多应用开发者之前并未编写过单元测试代码,那么如果有一篇通俗易懂并带有操作步骤的文章,能帮助应用开发者完成从单元测试小白到入门的过渡,就再好不过了,于是本文就是在
此情况写就的,如有不好之处,请多多包涵,谢谢。
1.2 术语和缩略语
2 闲谈单测
2.1 说说我理解的单测
2.1.1 对测试金字塔的理解
本文所指的单测,是金字塔最底层占70%的小型测试(单测) Unit tests,不包括最顶层占10%的大型测试(UI 测试) UI Tests,对于中间层20%的集成测试(集测),需看情况去做。
另外,集成测试更多是指验证一整个执行流程,而单测验证某个行为或逻辑,可以这么理解:集成测试验证执行流程时,会走单测验证过的某个行为或逻辑,即:单测可能是集成测试的一部分(不完全正
确,但可以这么理解)。
比如,Android 中需要在 Activity 显示一张网络图片,单测需验证网络请求图片是否成功,集测需验证从打开 Activity 到显示图片这一过程是否都按预期在执行,UI 测试验证 Activity 显示的图片是否如
预期一样。
2.1.2 为什么要做单测?
除了引言中背景提到的单测必要性之外,还有如下2点理由。
(1)一种代码验证,提高对代码的自信度
当我们对类函数代码做了修改或者重构,只需要再跑一遍单元测试
如果通过,说明我们的修改不会对函数原有的行为造成影响
如果测试不通过,说明我们的修改与原有行为不一致,要么修改代码,要么修改测试。
(2)驱动代码重构设计,代码重构质量的验证
刚开始,已有的代码可能基本没有办法写单测,会形成重构驱动,重构的过程会让代码逐渐具备良好的可测性
如果可以针对代码方便快速地,在无需做任何配置工作的情况下,编写一系列互相独立且稳定运行的测试,那么该代码就具备了可测性
具备可测性的代码必然是经过了良好设计的,形成可测性代码的过程,也就是编码技能提升的过程。
2.1.3 需要写 UI 测试吗?
Android 应用从广义来说,属于大前端,也就意味着 UI 变动会很频繁。且对于 UI 问题,应用开发者是很容易就能发现的,一般也比较容易解决。那么,针对 UI 进行测试其实是需要的,但没那么必要,
可以不用写 UI 测试。
不用写 UI 测试,除了上述提到的 2 个理由,另外还有这 2 个理由:Espresso 单测比较简单;测开会做 UI 测试。将重心放在单测上才是王道。
2.1.4 单测与重构
在没有进行合理的代码解耦前,就马上的进行单测编写,最终导致的有可能是编写不下去、用例难以维护、阅读性差等。
根本的原因其实是代码的耦合度过高,功能类与协作类之间是强引用关系(这里是指架构设计上的说法,非内存引用),当需要模拟协作类的一些返回结果来进行测试时,无法替换或者模拟(Mock)。
层级间、功能类间以接口的形式访问是一个较优的单测方式。
没写过单测的童鞋可能不知道,其实重构也是单测的一部分,切记不要在本就不优雅的代码上写单测,请先重构。单测为代码质量保驾护航,重构提升代码质量和自我编程能力。
2.1.5 TDD
项目如果走的敏捷开发,会涉及到测试驱动开发这一设计方法论,但说实话,在写代码前先写好测试代码,这对开发者能力要求很高,且目前国内开发环境其实对这块的理解并不如理想之见,暂无需考
虑。
2.1.6 单测写在哪?
首先,我们暂不写 UI 测试,只做单测,那么只需要在 src/test/java/包名/ 下写即可,一般来说可以不用在 src/androidTest/java/包名/ 下写单测代码。
其次,针对于 Android 应用,你可以在每个 Module 下都为其编写单测代码,然后统计各个 Module 的覆盖率,最后求一个平均覆盖率,即为整个应用的覆盖率。但,我们知道这其实是比较麻烦的,每
次统计时都需要去计算每个 Module 的覆盖率然后求平均,当然如果用 jacoco 可以优雅自动统计的话就另当别论。
所以,为了方便统计单测覆盖率,本文暂推荐在指定 Module 的 src/test/java/包名/ 下写所有 Module 的单测代码,这个指定 Module 可以是 app 模块,也可以是新建的专为写单测的 unit_test 模块。
2.1.7 单测三段式
经典的单测三段式:模拟前提、执行语句、断言结果。有时会把这三者的部分或全部合在一起,如:Assert.assertEquals(4, 2+2),就把三者融合在一起。
2.1.8 一个简单的测试例子
我们代码中经常会有日期工具类,下面是对有效日期判断的方法进行的测试例子。
(1)有效日期判断的源码
object DateUtils {
fun getValidDate(milliseconds: Long): Long {
var validDate = milliseconds
val timeInMillis = Calendar.getInstance(Locale.US).timeInMillis
if (milliseconds <= 0L || milliseconds > timeInMillis) {
validDate = timeInMillis
}
return validDate
}
}
(2)测试代码
@Test
fun testGetValidData() {
// 1、模拟前提
val currentTimeMillis1 = System.currentTimeMillis()
// 2、执行语句
val validDate1 = DateUtils.getValidDate(-1)
// 3、断言结果
Assert.assertTrue(validDate1 in (currentTimeMillis1 - 1000)..(currentTimeMillis1 + 1000))
val currentTimeMillis2 = System.currentTimeMillis()
val validDate2 = DateUtils.getValidDate(0)
Assert.assertTrue(validDate2 in (currentTimeMillis2 - 1000)..(currentTimeMillis2 + 1000))
val currentTimeMillis3 = System.currentTimeMillis()
val validDate3 = DateUtils.getValidDate(currentTimeMillis3 + 100000)
Assert.assertTrue(validDate3 in (currentTimeMillis3 - 1000)..(currentTimeMillis3 + 1000))
val milliseconds4 = System.currentTimeMillis() - 100000
val validDate4 = DateUtils.getValidDate(milliseconds4)
Assert.assertEquals(milliseconds4, validDate4)
}
2.2 单测针对于哪些代码进行
单测是指对软件中的最小可测试单元进行检查和验证,要以类功能作为测试目标的单个或者一连串的函数测试,也就是说,单测可以是对某个类的具体函数的功能、内部逻辑进行验证。
而针对代码复杂性和依赖性,有如下图的原则描述可参考:
·
复杂依赖少:适合写单测
· 复杂依赖多:重构减少依赖,变成复杂依赖少,然后写单测
· 简单依赖少:看情况写
· 简单依赖多:不用重构,不用单测
这里对代码简单依赖多的情况多提一嘴,对它们写单测意义并不大,不要为了提高单测覆盖率,而花费很多时间和精力去写单测,这样得不偿失。
2.3 测试用例该如何设计
2.3.1 确保原因与影响清晰
模拟前提条件和测试断言之间相隔了200行,这很难知道这断言是否正确,可读性差。
确保模拟前提与验证结果相近,查看问题时能快速定位。
2.3.2 只验证有状态变化的函数调用
对函数执行过程中验证不带来状态发生改变的函数是无意义的,例如isUserActive、getPermission、isVAlidPermission等都是对程序没有发生状态变化的,验证是否这类函数是否执行,只会增加后续代
码修改带来的不稳定。
正确应该只验证addPermission是否执行。
2.3.3 测试函数名应该有描述性
测试函数名应该具备可直接理解该测试用例的意图和验证结果,如下这种写法,很难让人知道测试目的是为了验证三次输入错误。
正确应该命名为:should_LockOutUser_when_ThreeInvalidLoginAttempts
should_期望结果_when_测试场景。确保测试用例名字中包括被测试的场景和期望的输出。
2.4 单测框架
Junit4 + Mockito(powerMock)+ robolectric
简单单测 + 模拟难以实例化的类 + 实现 Android 框架(更多内容请参考相应框架学习)
|
|