Android 单元测试实战(1)—— 调研与选型
单元测试搞了一段时间,发现网上很多关于单元测试的文章都是讲了概念,讲了框架的使用,但对于一个实际的项目的操作,因为项目的复杂性,框架的稳定性等,确往往无法进行。本篇博客从实际出发,基于实际的项目总结而出。
本系列文章不会涉及到单元测试的概念,以及它的各种现实意义。仅从实现入手,关于它的优劣不做分析。
单元测试系列会分为三篇博客:
- Android单元测试调研与选型
- 基于
Powermock
的Android单元测试常用方法指南 - 基于
Cobertra
&sonarqube
的单元测试覆盖率统计
调研与选型
Google
官方文提供了单元测试的支持。在创建项目的时候会默认创建test
和androidTest
目录。分别是单元测试和集成测试。单元测试是对方法的测试,粒度较小,无需运行在真机上。集成测试需要每次运行需要跑在真机上,粒度较大,运行时间较长,而且不利于一些自动化的工作。
本系列的核心从单元测试入手,以自动化为目的。
单元测试一个绕不开的话题就是对于android.jar
的问题。由于android.*
的官方类,在运行单元测试的时候,只有方法的声明,内部的所有方法都会throw new RuntimeException('Stub')
。那么一旦有调用官方类的地方,比如View
,Intent
,Activity
等,就会报错,导致单元测试无法执行。
一种常见的解决方式是通过架构来解决,将一些代码逻辑和官方类解耦,比如MVP
,对Presenter
做测试,因为大部分逻辑都在Presenter
,所以还ok。
但是不幸的,一般搞单元测试的时候,很难是从一个新项目入手的,架构很难变动,一旦修改架构,影响范围比较广。
而我们的项目就是这样的,所有的逻辑都在Activity
中编写,一旦测试逻辑就肯定绕不开官方类。
官方文档上提到了单元测试的两种解决方案。
一种是通过Mock
来解决,及将官方类的调用方法给代理一下,不会实际的调用官方类的相关方法。
另外一种是Robolectric
,该框架通过在jvm
上模拟android
虚拟机,以单元测试的方式来完成集成测试。
Robolectric
(放弃)
因为最终没有使用这个框架,所以先介绍一下这个框架。
该框架相当于是搭建了一个android
虚拟机,其运行单元测试的时候,实质是运行了一个app
。那么其做测试的逻辑更倾向于appium
等的UI
测试,查询一个控件,模拟点击,验证逻辑。
因为其模拟的虚拟机ÿ