Android单元测试＞整理分享

最新推荐文章于 2024-11-30 15:43:50 发布

liusaisaiV1

最新推荐文章于 2024-11-30 15:43:50 发布

阅读量494

点赞数

分类专栏： Android学习总结文章标签： java android 单元测试

本文链接：https://blog.csdn.net/liusaisaiV1/article/details/118898750

版权

Android学习总结专栏收录该内容

57 篇文章 5 订阅

订阅专栏

Android单元测试

单元测试？
What？
项目中为了测试某一个代码单元而写的测试代码；用于执行项目中的目标函数并验证其逻辑状态或者结果。这些代码是白盒测试，能够检测目标代码的准确性和可靠性，在打包时单元测试的代码并不会被编译进入release apk中。
Why？

提高信心
单元测试不能百分之百保证在集成联调时能够完全正确运行，但可以保证每一代码单元测试通过。
方便代码重构
使用单元测试可以边重构边写单元测试，保证重构没有破坏原有的代码逻辑的准确性。
写单元测试本身就是一次小范围的代码重构
这个过程中，可以发现逻辑设计上的问题，代码编写方面的问题，比如一些边界条件处理、空对象的保护和类构造时参数的依赖问题，还有一些对Android Context的依赖问题。
节约开发时间
如果没有单元测试的话，我们coding时为了调试某个功能，看界面是否显示正确，把APP运行起来，如果有错的话，改一点东西，再运行起来。。。有了单元测试，开发过程中可以更少的把APP运行起来，一两分钟的等待就可以验证代码逻辑是否正确，速度相对来说快很多。此外，通过单元测试能帮我们减少bug，从而减少了调试bug和fix bug的时间
更快的发现bug
如果没有单元测试，我们就需要在最后的集成联调中才能发现自己模块的问题，一旦问题比较严重的话，可能会让自己感觉有压力和恐慌。但是通过单元测试，可以有多一层的保证，可以更早的发现问题和解决问题，在集成时让自己更加闲庭信步。

一、Android现有测试框架及其优缺点

JUnit4
测试对象及环境：针对无复杂依赖情况；针对非私有、非静态、非全局的方法、类的测试；
用的最多的一个测试框架，Android Studio创建的工程中就默认集成了JUnit4，并添加了dependencies；
对应的单元测试代码则是放在src/test/java目录中，
编写：与IDEA类似，
@Test
public void testadd(int num1, int num2) {
MainActivity mainActivity = new MainActivity(); //before；创建待测类的对象
int sum = mainActivity.add(1,2); //on：调用待测方法
Assert.assertEquals(3,sum); //after：通过断言检测结果
}
运行：选中方法，右键 run 即可；
主要测试对象
1. 有明确的返回值；做单元测试时，只需调用这个函数，验证其返回值是否符合预期结果。
2. 这个函数只改变其对象内部的一些属性或者状态，函数本身没有返回值，就验证它所改变的属性和状态。
3. 一些函数没有返回值，也没有直接改变哪个值的状态，这就需要验证其行为，比如点击事件。???
4. 对于 b、c 两种情况，往往是验证目标方法中的某个对象的某个方法是否得到了调用，或者验证目标方法中的某个对象的某个状态是否发生改变，以此来验证目标方法是否按照我们想要的逻辑进行调用；
问题：对于项目中依赖资源复杂情况，处理困难；对于对象、集合、Map等数据结构的比较（断言的可读性不友好），可使用Hamcest框架进行比较；
Mockito
测试对象及环境：针对复杂依赖情况；针对非私有、非静态、非全局的方法、类的测试；
在测试环境中，通过Mockito mock出其他的依赖对象，用来替换真实的对象，使得待测的目标方法被隔离起来，避免外界因素的影响和依赖，能在我们预设的环境中执行，以达到两个目的：
1. 验证指定方法的调用情况，调用了多少次，参数是什么等等;
2. 指定该对象的某些方法的行为，返回特定的值，或是执行特定的动作；
问题：生成mock对象的原理有其局限性，如final类型、private类型以及静态类型的方法不能mock；
PowerMockito
测试对象及环境：针对复杂依赖情况；针对私有、静态、全局的方法、类的测试；
扩展了其它mock框架；PowerMock基本上 cover 了 Mockito 不能支持的 case；
使用JUnit4+Mockito+PowerMockito可完成大部分java测试
Powermock提供了mock和spy两种方式，对于 Activity 的私有方法的调用验证通常需要做方法模拟。mock 和 spy 都可以实现。
问题：对于依赖 Android SDK 的对象（如Activity，Button等），测试非常头疼；
Robolectric
测试对象及环境：针对依赖 Android SDK 的对象（如Activity，Button等）的测试
通过实现一套JVM能运行的Android代码，从而做到脱离Android环境进行测试。
可实现UI测试，查询一个控件，模拟点击，验证逻辑；
JUnit4+Mockito+PowerMockito+Robolectric
问题：因为我们的项目都是在Activity里面写的，一些业务逻辑都是使用私有方法，那么相对私有方法做验证，通过查询控件和通过UI的展示来验证逻辑的正确与否，十分的复杂。需要使用Powermock。
注意：Powermock和Robolectric存在着兼容问题，如果出现问题无法解决，可尝试放弃Robolectric
UIAutomator和Espresso；
Google开源的测试框架，基于Instrumentation，更偏向于UI方面的自测化测试。
Espresso功能强大、执行速度很快的，但是它有一个重要的局限：只可以在被测App的Context中操作。意味着下列App自动化测试需求无法实现：应用的推送消息、同步联系人、从另一个应用程序进入被测App。
UIAutomator 2.0 发布后可以实现上述功能；采用脚本语言编写，集成失败…UIAutomator集成测试失败；
robotium；UI测试用例
ActivityUnitTestCase、ActivityInstrumentationTestCase2
由Android提供的Instrumentation系统如，将单元测试代码运行在模拟器或者是真机上。虽然这种方式可以work，但是速度非常慢。

二、确定Android 测试框架

JUnit4

Mockito
PowerMockito

Robolectric
UIAuutomator / Espresso
robotium
ActivityUnitTestCase / ActivityInstrumentationTestCase2
项目中依赖复杂的情况

✅
✅
✅

依赖Android SDK 的情况

✅

UI测试

✅
✅
✅
测试私有、全局、静态

✅

JUnit4 + Mockito + PowerMockito + Robolectric
使用：JUnit4 + PowerMockito

三、单元测试怎么写，非界面的逻辑部分的单元测试怎么写
在Android studio project中，源代码默认放在src/main/java下面的，
对应的Java相关的单元测试代码则是放在src/test/java目录中；
src/androidTest/java中存放的是Android相关的单元测试代码

JUnit4
依赖：默认是有的：testImplementation “junit:junit:$junit_version”
以 tosee-sdk 为例；src/main/java/tech/tosee/combine/models/TSPeer.kt
单元测试
非界面的单元测试

创建测试类。右键类名，选择GOTO 选择Test
选择JUnit4；勾选待测试的方法或属性（私有方法没有显示）；注意，点击OK后会提示保存目录：Java相关代码则是放在src/test/java目录中；Android相关的单元测试代码在src/androidTest/java中
代码补全
@Test
fun testEquals() {
//before 实例化待测试的目标类，以及设计一些前提条件：
val tsPeer: TSPeer = TSPeer(“userId”, “gmsUserId”, “nickname”, “merchantId”, “rtcUserId”)
//on 执行操作，调用待测试的那个方法，同时获得结果：
val equals = tsPeer.equals(TSPeer(“userid”, “gmsUserId”, “nickName”, “merchantid”, “rtcUserid”))
print(“================================” + equals)//这个不被打
Log.i(TAG, "testEquals: ")
//after验证结果，通过断言来验证结果是否与预期一样：
assertTrue(equals)
}
运行测试方法。右键方法名，run
注解：
@BeforeClass：针对所有测试，只执行一次，且必须为static void
@Before：初始化方法对于每一个测试方法都要执行一次（注意与BeforeClass区别，后者是对于所有方法执行一次）
@Test：测试方法，在这里可以测试期望异常和超时时间
@Test(expected=ArithmeticException.class)检查被测方法是否抛出ArithmeticException异常
@Ignore：忽略的测试方法
@After：释放资源对于每一个测试方法都要执行一次（注意与AfterClass区别，后者是对于所有方法执行一次）
@AfterClass：针对所有测试，只执行一次，且必须为static void

PowerMockito

依赖：
testImplementation “org.mockito.kotlin:mockito-kotlin:3.2.0”
// PowerMock brings in the mockito dependency
testImplementation “org.powermock:powermock-module-junit4:2.0.4”
testImplementation “org.powermock:powermock-module-junit4-rule:2.0.4”
testImplementation “org.powermock:powermock-api-mockito2:2.0.4”
testImplementation “org.powermock:powermock-classloading-xstream:2.0.4”

如遇问题推荐阅读：Android 单元测试之PowerMock

注解：
@RunWith(PowerMockRunner.class)
@PrepareForTest({YourClassWithEgStaticMethod.class})
@PowerMockIgnore(“javax.management.*”)

若测试用例没有用@PrepareForTest，那么不用加@RunWith(PowerMockRunner.class)，反之亦然。
当你需要使用PowerMock进行Mock静态、final、私有方法等时候，就需要加@PrepareForTest。要么使用这种注解的方式：
@RunWith(PowerMockRunner.class)
@PrepareForTest({YourClassWithEgStaticMethod.class})

要么使用注解加代码的方式
@PrepareForTest({YourClassWithEgStaticMethod.class})
MockitoAnnotations.initMocks(this);

注：@PrepareForTest({Example1.class, Example2.class, …}) //声明多个静态类

普通Mock：Mock参数传递的对象（不需要加注解）

待测代码
class CommonExampleKotlin {
fun callArgumentInstance(file: File): Boolean {
return file.exists()
}
}
测试代码
class CommonExampleKotlinTest {
@Test
fun testCallArgumentInstance() {
//1。创建一个mock对象
val file = PowerMockito.mock(File::class.java)
val commonExample = CommonExample()
//2。指定mock对象具体的行为
PowerMockito.when(file.exists()).thenReturn(true)
//3。将mock对象作为参数传递给测试方法，执行测试方法。
assertTrue(commonExample.callArgumentInstance(file))
}
}

Mock 方法内部new出来的对象
当使用 PowerMockito.whenNew 方法时，必须加注解 @PrepareForTest 和 @RunWith 。@PrepareForTest 里写的类是需要 mock 的 new 对象代码所在的类。

待测代码 1
class CommonExampleKotlin {
/**
- 1. Mock方法内部new出来的对象
    */
    fun callArgumentInstance(path: String?): Boolean {
    val file = File(path)
    return file.exists()
    }
    }
测试代码 1
@Test
//@RunWith(PowerMockRunner::class.java)
@PrepareForTest(CommonExampleKotlin::class)
//2) Mock方法内部new出来的对象
fun testCallArgumentInstance2() {
//代码实现RunWith
MockitoAnnotations.initMocks(this);
//1。创建一个mock对象
val file = PowerMockito.mock(File::class.java)
val commonExampleKotlin = CommonExampleKotlin()
//2。指定当以参数为"fileName"创建File对象的时候，返回已经mock的File对象。
PowerMockito.whenNew(File::class.java).withArguments(“fileName”).thenReturn(file)
//3。指定mock对象具体的行为
PowerMockito.when(file.exists()).thenReturn(true)
//实际上此处该方法并未成功创建文件，
assertTrue(!commonExampleKotlin.callArgumentInstance(“fileName”))
val newFile = Mockito.mock(File::class.java)
newFile.exists()
Mockito.verify(newFile).exists()
}
待测代码 2
public class EmployeeService {
public int getTotalEmployee() {
EmployeeDao employeeDao = new EmployeeDao();
return employeeDao.getTotal();
}
}
测试代码 2
getTotalEmployee（）因为测试的时候是不能修改这个方法的，不管里面是什么东西，局部变量我们也是无法触摸的，所以！智能模拟，不能更改，这个改正很可能造成系统的缺陷。不注意就完了。非常的需要小心，作为测试人员的话！

/**

采用 PowerMock 进行测试
*/
@Test
public void testGetTotalEmployeeWithMock() {
EmployeeDao employeeDao = PowerMockito.mock(EmployeeDao.class);
try {
//没得参数的够造！返回模拟的局部变量！
PowerMockito.whenNew(EmployeeDao.class).withNoArguments()
.thenReturn(employeeDao);
PowerMockito.when(employeeDao.getTotal()).thenReturn(10);
EmployeeService service = new EmployeeService();
int total = service.getTotalEmployee();
assertEquals(10, total);
} catch (Exception e) {
fail(“测试失败.”);
}
}
}

Mock普通对象的 final 方法

待测代码
class CommonDependency {
/**
- 1. Mock普通对象的final方法
    */
    final fun isAlive(): Boolean {
    // do something
    return false
    }
    }

class CommonExampleKotlin {
/**
* 3) Mock普通对象的final方法
*/
open fun callFinalMethod(example: CommonDependency): Boolean {
return example.isAlive()
}
}

测试代码
@Test
//final方法所在的类。
@PrepareForTest(CommonDependency::class)
fun testCallFinalMethod() {
val mock: CommonDependency = PowerMockito.mock(CommonDependency::class.java)
val commonExampleKotlin = CommonExampleKotlin()
PowerMockito.when(mock.isAlive()).thenReturn(true)
assertTrue(commonExampleKotlin.callFinalMethod(mock))
}
注意：如果使用 PowerMockito.mock 报错 ockito cannot mock/spy because : - final class
添加依赖：
//Mockito
testImplementation “org.mockito:mockito-inline:3.3.3”
androidTestImplementation ‘org.mockito:mockito-android:3.3.3’

Mock静态类的静态方法

待测代码
class CommonExampleKotlin {
/**
- 1. Mock普通类的静态方法
    */
    fun printUUID(): String {
    return Utils.generateNewUUId()
    }
    }
静态类
object MUtils {
@JvmStatic
open fun generateNewUUId(): String {
return UUID.randomUUID().toString()
}
}
测试代码
//语句告诉JUnit用PowerMockRunner来执行测试。
@RunWith(PowerMockRunner::class)
//语句告诉PowerMock准备Employee类进行测试。适用于模拟final类或有final, private, static, native方法的类。
@PrepareForTest(Utils::class)
class CommonExampleKotlinTest {
//4) ??? Mock普通类的静态方法
val res = “Return UUID”
@Test
fun testPrintUUID() {
val commonExampleKotlin = CommonExampleKotlin()
```
  PowerMockito.mockStatic(MUtils::class.java)
  PowerMockito.`when`(MUtils.generateNewUUId()).thenReturn(res)
  print(commonExampleKotlin.printUUID())
  assert(res.equals(commonExampleKotlin.printUUID()))
```
}
}

Mock 私有方法

待测方法
class CommonExampleKotlin {
/**
- 1. Mock 私有方法
    */
    fun callPrivateMethod(): Boolean {
    return isExist()
    }
private fun isExist(): Boolean {
return false
}
}
测试代码
//语句告诉JUnit用PowerMockRunner来执行测试。
@RunWith(PowerMockRunner::class)
//语句告诉PowerMock准备Employee类进行测试。适用于模拟final类或有final, private, static, native方法的类。
@PrepareForTest(CommonExampleKotlin::class)
class CommonExampleKotlinTest {
//5）mock 私有方法
@Test
fun testCallPrivateMethod() {
val mock:CommonExampleKotlin = PowerMockito.mock(CommonExampleKotlin::class.java)
PowerMockito.when(mock.callPrivateMethod()).thenCallRealMethod()
PowerMockito.when(mock, “isExist”).thenReturn(true)
print(mock.callPrivateMethod())
assertTrue(mock.callPrivateMethod())
}
}

Mock系统类的静态和final方法

待测代码
class CommonExampleKotlin {
/**
- 1. Mock系统类的静态和final方法
    */
    fun callSystemStaticMethod(str: String?): String {
    return System.getProperty(str)
    }
    }
测试代码
//语句告诉JUnit用PowerMockRunner来执行测试。
@RunWith(PowerMockRunner::class)
//语句告诉PowerMock准备Employee类进行测试。适用于模拟final类或有final, private, static, native方法的类。
//@PrepareForTest(Utils::class)
@PrepareForTest(CommonExampleKotlin::class)
class CommonExampleKotlinTest {
//6) Mock系统类的静态和final方法
@Test
fun testcallSystemStaticMethod() {
val commonExample = CommonExampleKotlin();
PowerMockito.mockStatic(System::class.java);
PowerMockito.when(System.getProperty(“aaa”)).thenReturn(“bbb”);
assertEquals(“bbb”, commonExample.callSystemStaticMethod(“aaa”));
}
}

Mock普通类的私有变量

待测代码
class CommonExampleKotlin {
/**
- 1. Mock普通类的私有变量
    */
    private val STATE_NOT_READY: Int = 0
    private val STATE_READY = 1
    private val mState = STATE_NOT_READY
fun doSomethingIfStateReady(): Boolean {
return if (mState == STATE_READY) {
// DO some thing
true
} else {
false
}
}
}
测试代码
class CommonExampleKotlinTest {
//7) Mock普通类的私有变量
@Test
fun testdoSomethingIfStateReady() {
val sample = CommonExampleKotlin()
Whitebox.setInternalState(sample, “mState”, 1)
assertTrue(sample.doSomethingIfStateReady())
}
}

注：当需要mock私有变量mState的时候，不需要加注解@PrepareForTest和@RunWith，而是使用Whitebox来mock私有变量mState并注入你预设的变量值。

四、单元测试的覆盖率统计怎么做

概念：
程序中源代码被测试的比例和程度，所得比例称为代码覆盖率。
指标
分支（C1 Coverage）：对所有的if和switch语句计算分支覆盖率。统计在方法中分支执行数量、未执行数量的信息。但要注意，异常处理不在此计算范围内。
行（Lines）：一行可能包含一条或多条指令，如果至少有一条指令被执行了，那么该行就算作是被执行了。
方法（Methods）：每个非抽象方法至少包含一条指令。如果至少有一条指令被执行了，那么该方法就算作是被执行了。
类（Classes）：如果类中至少有一个方法被执行了，那么该类就算作是被执行了。
指令（C0 Coverage）：JaCoCo计数的最小单元是单一的Java字节码指令。指令覆盖率提供了关于字节码执行数量、未执行数量的信息。
圈复杂度（Cyclomatic Complexity）：对非抽象方法计算圈复杂度，并汇总类、包和组的（圈）复杂度。这个值可以做为单元测试用例是否完全覆盖的参考。
使用方法