Android单元测试之 Mockito

它有这些好处：

　　· 团队提效

　　当使用mock之后，各团队之间可以不需要再互相等待对方的进度，只需要约定好相互之间的数据规范（文档），即可使用mock构建一个可用的接口，然后尽快的进行开发和调试以及自测，提升开发进度的的同时，也将发现缺陷的时间点大大提前。

　　· 开启TDD（Test-Driven Development）模式，即测试驱动开发

　　单元测试是TDD实现的基石，而TDD经常会碰到协同模块尚未开发完成的情况，但是有了mock，这些一切都不是问题。当接口定义好后，测试人员就可以创建一个Mock，把接口添加到自动化测试环境，提前创建测试。

　　· 测试覆盖率

　　假如有一个接口，有100个不同类型的返回，我们需要测试它在不同返回下，系统是否能够正常响应，但是有些返回在正常情况下基本不会发生，难道你要千方百计地给系统做各种手脚让他返回以便测试吗？比如，我们需要测试在当接口发生500错误的时候，app是否崩溃，别告诉我你一定要给服务端代码做些手脚让他返回500 。。。而使用mock，这一切就都好办了，想要什么返回就模拟什么返回，妈妈再也不用担心我的测试覆盖度了！

　　· 隔离系统 / 依赖隔离

　　假如我们需要调用一个post请求，为了获得某个响应，来看当前系统是否能正确处理返回的“响应”，但是这个post请求会造成数据库中数据的污染，那么就可以充分利用Mock，构造一个虚拟的post请求，我们给他指定返回就好了。

　　Mock例子

　　一个闹钟根据时间来进行提醒服务，如果过了下午5点钟就播放音频文件提醒大家下班了，如果我们要利用真实的对象来测试的话就只能苦苦等到下午五点，然后把耳朵放在音箱旁，我们应该利用mock对象来进行测试，这样我们就可以模拟控制时间了，而不用苦苦等待时钟转到下午5点钟了。下面是代码：

1. public abstract class Environmental{

2. 　　// 是否正在播放音频

3. 　　boolean playedWav=false;

4. 　　// 获取当前时间

5. 　　public abstract long getTime();

6. 　　// 播放音频

7. 　　public abstract void playWavFile(String fileName);

8. 　　// 音频是否在播放

9. 　　public abstract boolean wavWasPlayed();

10. 　　// 重置音频

11. 　　public abstract void resetWav();

12. 　　}

　业务代码：

1. 　public class SystemEnvironment extends Environmental{

2. 　　public long getTime(){

3. 　　return System.currentTimeMillis();

4. 　　}

5. 　　public void playWavFile(String fileName){

6. 　　playedWav=true;

7. 　　}

8. 　　public boolean wavWasPlayed(){

9. 　　return playedWav;

10. 　　}

11. 　　public void resetWav(){

12. 　　playedWav=false;

13. 　　}

14. 　　}

　下面是Mock对象，我们来Mock我们写好的方法

1. public class MockSystemEnvironment extends Environmental{

2. 　　private long currentTime;

3. 　　public long getTime(){

4. 　　return currentTime;

5. 　　}

6. 　　public void setTime(long currentTime){

7. 　　this.currentTime=currentTime;

8. 　　}

9. 　　public void playWavFile(String fileName){

10. 　　playedWav=true;

11. 　　}

12. 　　public boolean wavWasPlayed(){

13. 　　return playedWav;

14. 　　}

15. 　　public void resetWav(){

16. 　　playedWav=false;

17. 　　}

18. 　　}

这样我们通过Mock出来的对象，就可以随时模拟时间的流动的。

　　Mockito介绍

　　Mockito是Mock框架下的一种实现，所以Mockito的测试思想就是Mock的测试思想。

　　目前Android较为普遍的单元测试工具的使用就是 Junit4+Mocikto， 除了Mockito还有像 powermock、jmock，从名字上就可以看出他们都离不开Mock对象。

　　注意 Junit和Mockito是可以组合使用的，它们本身并不冲突，反而相得益彰。

　　Mockito的使用

　　导入

　　Mockito在mockito包下，所以和junit4不一样，需要我们手动导入:

1. dependencies {

2. 　　…

3. 　　testImplementation “org.mockito:mockito-core:3.3.3”

4. 　　androidTestImplementation ‘org.mockito:mockito-android:3.3.3’

5. 　　}

Mock类声明

　　我们来Mock一个List

1. 　var myList: MutableList? = null

2. 　　@Before

3. 　　fun setUp() { // 初始化的函数

4. 　　myList= mock(MutableList::class.java)

5. 　　}

在测试开始，我们需要在初始化函数里面对需要Mock的对象调用 mock()方法来进行声明，或者我们可以通过注解的方式来声明：

1. 　@Mock

2. 　　var myList: MutableList? = null

3. 　　@Before

4. 　　fun setUp() {

5. 　　MockitoAnnotations.initMocks(this)

6. 　　}

亦或是直接使用Junit的 @RunWith注解，进行初始化：

1. 　　@RunWith(MockitoJUnitRunner::class)

2. 　　class MyUnitTest {

3. 　　@Mock

4. 　　var myList: MutableList? = null

5. 　　…

6. 　　}

verify

　　verify()用于检查是否发生了某些行为。我们可以在测试方法代码的末尾使用Mockito验证方法，以确保调用了指定的方法。

　　我们可以使用verifyNoMoreInteractions()来确保所有内容均已通过验证。如果仍然有任何方法验证，它将失败并提供正确的消息。

　　verifyZeroInteractions()行为与verifyNoMoreInteractions()方法相同。

　　我们可以使用inOrder()方法来验证方法调用的顺序。

　　来看一下代码：

1. 　@Test

2. 　　fun test() {

3. 　　myList?.add(1)

4. 　　myList?.clear()

5. 　　verify(myList)?.add(1)

6. 　　verify(myList)?.clear()

7. 　　}

还可以用来验证调用的次数，下面是用verify来判断函数调用了多少次：

1. @Test

2. 　　fun test() {

3. 　　myList?.size

4. 　　verify(myList, times(0))?.add(1) // 判断add被调用了0次

5. 　　verify(myList, times(1))?.size // 判断size被调用了1次

6. 　　verify(myList, atLeast(1))?.size // 判断size被调用了至少一次

7. 　　verify(myList, atLeastOnce())?.size // 同上，相同于atLiast(1)

8. 　　verify(myList, atMost(2))?.size // 判断size被调用少于2次

9. 　　verify(myList, never())?.clear() // 判断clear没有被调用过

10. 　　verify(myList, only())?.clear() // 判断是否只调用过clear方法

11. 　　}

verifyNoMorInteractions /

　　该方法调用后，表明之后再也没有Mock对象的交互了，所以一般用在测试方法的最后面。

　　// 表明之后再也没有myList的事情了， 这个地方可以跑通

　　verifyNoMoreInteractions(myList);

　　// 又操作了myList

　　myList.isEmpty();

　　// 因为之前已经声明不会再调用myList了，这里做了检查发现它使用过，所以这里会报错

　　verifyNoMoreInteractions(myList);

　　verifyZeroInteractions() 和该方法行为相同，不作赘述。

　　InOrder

　　可以使用 InOrder来验证调用的顺序：

1. 　@Test

2. 　　fun test() {

3. 　　myList .size

4. 　　mySet .add(100)

5. 　　myList .add(1)

6. 　　myList .add(2)

7. 　　myList .clear()

8. 　　mySet .clear()

9. 　　val inOrder = inOrder(myList, mySet)

10. 　　inOrder.verify(myList) .size

11. 　　inOrder.verify(mySet) .add(100)

12. 　　inOrder.verify(myList) .add(2)

13. 　　// 测试可以通过

14. 　　}

用来判断调用方法的顺序，也可以加入多个对象。

　　它就像字符串匹配中不连续子串的匹配~

　　when

　　when 像一个监听器，当事件触发时，会回调你想要的操作

　　下面是一个例子：

1. 　@RunWith(MockitoJUnitRunner::class)

2. 　　class MyUnitTest {

3. 　　@Mock

4. 　　var myList: MutableList? = null

5. 　　@Before

6. 　　fun setUp() {

7. 　　// 定义Mock行为，当调用 get（任何数）时，返回100

8. 　　when(myList?.get(ArgumentMatchers.anyInt())).thenReturn(100)

9. 　　}

10. 　　@Test

11. 　　fun test() {

12. 　　// 调用Mock对象的行为

13. 　　val res = myList?.get(1)

14. 　　// 比较实际结果与预期结果

15. 　　assertEquals(res, 100)

16. 　　//测试通过

17. 　　}

18. 　　}

在初始化函数中，使用when()对Mock对象进行了监听，thenReturn() 就是回调，相当于Hook了Mock对象的返回结果。

　　除了thenReturn()，还有其他回调的Api，比如：

　　thenThrow() // 抛出一个异常

　　thenCallRealMethod() // 回调某个已经实现的方法

　　thenAnswer() // 捕捉数据别回调重写的方法

　　then() // 和 thenAnswer一样

　　doThrow

　　注：不知道为啥，使用Kotlin后，doThrow会莫名执行错误，而Java则没有问题，网上也没有找到解决办法，所以这里使用Java演示，可能Mokito使用在Kt上还是有一些坑的。

　　上一节中，有个语句是 when(...).thenThrow()，但是如果我们 when语句里的方法是 void返回类型，则编译不通过，如下：

1. 　public class ExampleService

2. 　　{

3. 　　public void hello(){

4. 　　System.out.println(“hello”);

5. 　　}

6. 　　}

7. 　　…

8. 　　when(exampleService.hello()).thenThrow(new RuntimeException());

9. 　　// 编译报错

这是因为 when语句的返回不能为void，所以这个时候需要使用 doThrow来解决：

1. public class ExampleServiceTest

2. 　　{

3. 　　@Mock

4. 　　ExampleService exampleService;

5. 　　@Before

6. 　　public void setUp()

7. 　　{

8. 　　MockitoAnnotations.initMocks(this);

9. 　　doThrow(new RuntimeException()).when(exampleService).hello();

10. 　　}

11. 　　@Test(expected = RuntimeException.class)

12. 　　public void test()

13. 　　{

14. 　　exampleService.hello();

15. 　　}

16. 　　}

除了 doThrow()，还有其他针对于 void型函数的监听，比如：

　　doNothing() // 什么都不做

　　doReturn() // 返回一个值

　　doAnswer() // 回掉一个函数

　　Mokito spy和 @Spy

　　Mokito下测试除了针对于Mock类，还有 Spy类。

　　spy类介绍

　　spy类和mock类不同，他们有以下区别：

　　mock对象：完全虚构，除了自定义的行为之外，没有其他行为

　　spy对象：部分虚构对象，除了自定义行为外，其他行为参考真实对象的行为

　　也就是说 Mock对象是完全由虚拟数据构成的对象，而Spy对象则会监听真实对象的行为，又自定义了部分的行为。

　　spy对象的声明

　　声明spy对象和mock差不多，如下所示：

　　Spy类：

1. open class MathHelper {

2. 　　/**

3. 　　计算斐波那契

4. 　　*/

5. 　　fun factorial(n: Int): Int {

6. 　　return when {

7. 　　n < 0 -> {

8. 　　throw Exception(“负数没有阶乘”)

9. 　　}

10. 　　n <= 1 -> {

11. 　　1

12. 　　}

13. 　　else -> {

14. 　　n * factorial(n - 1)

15. 　　}

16. 　　}

17. 　　}

18. 　　}

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取