Android最佳Mock单元测试方案:Junit + Mockito + Powermock

简介: 本文旨在从实践出发,引导开发者在Android项目中进行Mock单元测试。 什么是单元测试 单元测试由一组独立的测试构成,每个测试针对软件中的一个单独的程序单元。单元测试并非检查程序单元之间是否能够合作良好,而是检查单个程序单元行为是否正确。 为什么要进行单元测试 在敏捷开发大行其道的今天,

本文旨在从实践出发,引导开发者在Android项目中进行Mock单元测试。

什么是单元测试

单元测试由一组独立的测试构成,每个测试针对软件中的一个单独的程序单元。单元测试并非检查程序单元之间是否能够合作良好,而是检查单个程序单元行为是否正确。

为什么要进行单元测试

在敏捷开发大行其道的今天,由于时间紧,任务重,过分依赖测试工程师以及下列原因,导致单元测试不被重视,在开发流程中处于一个可有可无的尴尬境地。

  1. 浪费的时间太多
  2. 软件开发人员不应参与单元测试
  3. 我是很棒的程序员,不需要进行单元测试
  4. 不管怎样,集成测试将会抓住所有的Bug
  5. 单元测试效率不高

那么单元测试是否正的可有可无呢?No! No! No!

  1. 作为android客户端研发,在一个开发周期内,你负责的需求需要Web服务(API),和本地代码(JNI,Native Code)的支持,而你们的工作是同时进行的。
  2. 你的需求开发完成了,但是由于需要在特定条件下才能触发,而这些条件在开发过程中很难去模拟,导致需求无法在所有场景下进行充分测试。举个例子,假设你在室内开发一个地图导航的Android应用,你需要在导航过程中,前方出现车祸,积水,施工等多种状况,怎么办?
  3. 总结你过去的BUG,你会发现有些你以为写的很完善的逻辑,却在最后被发现有场景未覆盖,或者逻辑错误等问题。
  4. 测试工程师给你报了一个BUG,你改完提交了,但是之后由于Merge失误导致代码丢失,或者其他人的修改导致你的BUG再次出现。直到测试工程师再次发现该BUG,并再次给你提出。
  5. 你的开发进度很快,但是开发完成后,你会被BUG淹没。你持续不断的修改BUG,持续不断的加班,直至发布版本,身心俱疲。
  6. 以前明明很正常的功能,在本次开发周期内,突然不能正常使用了。
    ...

如果你也经常碰到以上问题,或者困扰,那么你需要持续不断的对项目进行单元测试

Android单元测试简介

Android的单元测试分为两大类:

1.Instrumentation

通过Android系统的Instrumentation测试框架,我们可以编写测试代码,并且打包成APK,运行在Android手机上。

优点: 逼真
缺点: 很慢

代表框架:JUnit(Android自带),espresso

2.JUnit / Mock

通过JUnit,以及第三方测试框架,我们可以编写测试代码,生成class文件,直接运行在JVM虚拟机中。

优点: 很快。使用简单,方便。
缺点: 不够逼真。比如有些硬件相关的问题,无法通过这些测试出来。

代表框架: JUnit(标准),Robolectric, mockito, powermock

Android最佳Mock单元测试方案

我通过对比前辈们对各种单元测试框架的实践,总结出Android最佳Mock单元测试方案: Junit + Mockito + Powermock.(自己认证的...)

Junit + Mockito + Powermock 简介

众所周知,Junit是一个简单的单元测试框架。
Mockito,则是一个简单的用于Mock的单元测试框架。

那么为什么还需要Powermock呢?
EasyMock和Mockito等框架,对static, final, private方法均是不能mock的。
这些框架普遍是通过创建Proxy的方式来实现的mock。 而PowerMock是使用CGLib来操纵字节码而实现的mock,所以它能实现对上面方法的mock。

Junit + Mockito + Powermock 引入

由于PowerMock对Mockito有较强依赖,因此需要按照以下表格采用对应的版本。

Mockito PowerMock
2.0.0-beta - 2.0.42-beta 1.6.5+
1.10.8 - 1.10.x 1.6.2+
1.9.5-rc1 - 1.9.5 1.5.0 - 1.5.6
1.9.0-rc1 & 1.9.0 1.4.10 - 1.4.12
1.8.5 1.3.9 - 1.4.9
1.8.4 1.3.7 & 1.3.8
1.8.3 1.3.6
1.8.1 & 1.8.2 1.3.5
1.8 1.3
1.7 1.2.5

建议方案:
在项目依赖文件build.gradle中添加以下依赖。

testCompile 'junit:junit:4.11'
// required if you want to use Mockito for unit tests
testCompile 'org.mockito:mockito-core:1.9.5'
// required if you want to use Powermock for unit tests
testCompile 'org.powermock:powermock-module-junit4:1.5.6'
testCompile 'org.powermock:powermock-module-junit4-rule:1.5.6'
testCompile 'org.powermock:powermock-api-mockito:1.5.6'

Junit + Mockito + Powermock 配置

  1. 默认的测试代码位置
    对于通过gradle构建的android项目,在默认的项目结构中,Instrumentation的测试代码放在

src/androidTest/ 目录,而JUnit / Mock的测试代码放在 src/test/ 目录。

  1. 自定义测试代码位置
    有些项目是由Eclipse构建迁移到由Gradle构建,需要自定义测试代码位置。

举个例子,androidTest和test目录都在项目的根文件夹下。我们需要这样配置:

android {  
  sourceSets {
    test {
      java.srcDir 'test'
    }
    androidTest {
      java.srcDir 'androidTest'
    }
  }
}

如果在单元测试中遇到类似"Method ... not mocked."的问题,请添加以下设置:

android {
  // ...
  testOptions { 
    unitTests.returnDefaultValues = true
  }
}

Junit + Mockito + Powermock 使用

强烈建议你熟读以下内容,来熟悉Junit + Mockito + Powermock的使用。

  1. Mockito 中文文档 ( 2.0.26 beta )
  2. Mockito reference documentation
  3. powermock wiki
  4. Unit tests with Mockito - Tutorial

下面通过举例来简单说明Junit + Mockito + Powermock 使用,更多详情清参考Demo项目:
https://github.com/snowdream/test/tree/master/android/test/mocktest

源码: https://github.com/snowdream/test/blob/master/android/test/mocktest/app/src/main/java/snowdream/github/com/mocktest/Calc.java

测试代码:https://github.com/snowdream/test/blob/master/android/test/mocktest/app/src/test/java/snowdream/github/com/mocktest/CalcUnitTest.java

1.验证某些行为,主要是验证某些函数是否被调用,以及被调用的具体次数。

//using mock
mockedList.add("once");

mockedList.add("twice");
mockedList.add("twice");

mockedList.add("three times");
mockedList.add("three times");
mockedList.add("three times");

//following two verifications work exactly the same - times(1) is used by default
// 下面的两个验证函数效果一样,因为verify默认验证的就是times(1)
verify(mockedList).add("once");
verify(mockedList, times(1)).add("once");

//exact number of invocations verification
// 验证具体的执行次数
verify(mockedList, times(2)).add("twice");
verify(mockedList, times(3)).add("three times");

//verification using never(). never() is an alias to times(0)
// 使用never()进行验证,never相当于times(0)
verify(mockedList, never()).add("never happened");

//verification using atLeast()/atMost()
// 使用atLeast()/atMost()
verify(mockedList, atLeastOnce()).add("three times");
verify(mockedList, atLeast(2)).add("five times");
verify(mockedList, atMost(5)).add("three times");

2.验证执行顺序,主要验证某些函数是否按照预定顺序执行。

// A. Single mock whose methods must be invoked in a particular order
// A. 验证mock一个对象的函数执行顺序
List singleMock = mock(List.class);

//using a single mock
singleMock.add("was added first");
singleMock.add("was added second");

//create an inOrder verifier for a single mock
// 为该mock对象创建一个inOrder对象
InOrder inOrder = inOrder(singleMock);

//following will make sure that add is first called with "was added first, then with "was added second"
// 确保add函数首先执行的是add("was added first"),然后才是add("was added second")
inOrder.verify(singleMock).add("was added first");
inOrder.verify(singleMock).add("was added second");

// B. Multiple mocks that must be used in a particular order
// B .验证多个mock对象的函数执行顺序
List firstMock = mock(List.class);
List secondMock = mock(List.class);

//using mocks
firstMock.add("was called first");
secondMock.add("was called second");

//create inOrder object passing any mocks that need to be verified in order
// 为这两个Mock对象创建inOrder对象
InOrder inOrder = inOrder(firstMock, secondMock);

//following will make sure that firstMock was called before secondMock
// 验证它们的执行顺序
inOrder.verify(firstMock).add("was called first");
inOrder.verify(secondMock).add("was called second");

// Oh, and A + B can be mixed together at will

3.使用powermock必须使用两个annotation:

@RunWith(PowerMockRunner.class)
@PrepareForTest({Calc.class})
public class CalcUnitTest {
}
//PrepareForTest 后面要加准备被mock或stub的类,单个class直接()起来即可,多个用{},并用逗号隔开。

4.测试公开成员变量

@Test
public void testPublicField() {
    assertEquals(mCalc.mPublicField, 0);
    assertEquals(mCalc.mPublicFinalField, 0);
    assertEquals(Calc.mPublicStaticField, 0);
    assertEquals(Calc.mPublicStaticFinalField, 0);

    mCalc.mPublicField = 1;
    Calc.mPublicStaticField = 2;

    assertEquals(mCalc.mPublicField, 1);
    assertEquals(mCalc.mPublicFinalField, 0);
    assertEquals(Calc.mPublicStaticField, 2);
}

5.测试公开成员方法

@Test
public void testAddPublicMethod() {
    //when
    when(mCalc.addPublic(anyInt(), anyInt()))
            .thenReturn(0)
            .thenReturn(1)
            .thenReturn(2)
            .thenReturn(3)
            .thenReturn(4)
            .thenReturn(5);

    //call method
    for (int i = 0; i < 6; i++) {

        //verify
        assertEquals(mCalc.addPublic(i, i), i);
    }

    //verify
    verify(mCalc, times(6)).addPublic(anyInt(), anyInt());
    verify(mCalc, atLeast(1)).addPublic(anyInt(), anyInt());
    verify(mCalc, atLeastOnce()).addPublic(anyInt(), anyInt());
    verify(mCalc, atMost(6)).addPublic(anyInt(), anyInt());
}

6.测试公开无返回值成员方法

@Test
public void testAddPublicVoidMethod() {
    //when
    doNothing().when(mCalc).voidPublic(anyInt(), anyInt());

    mCalc.voidPublic(anyInt(), anyInt());
    mCalc.voidPublic(anyInt(), anyInt());

    verify(mCalc, atLeastOnce()).voidPublic(anyInt(), anyInt());
    verify(mCalc, atLeast(2)).voidPublic(anyInt(), anyInt());
}

7.测试公开静态成员方法


    @Test
    public void testAddPublicStaicMethod() throws Exception {
        PowerMockito.mockStatic(Calc.class);

        PowerMockito.when(Calc.class, "addPublicStatic", anyInt(), anyInt())
                .thenReturn(0)
                .thenReturn(1)
                .thenReturn(2)
                .thenReturn(3)
                .thenReturn(4)
                .thenReturn(5);


        //call method
        for (int i = 0; i < 6; i++) {

            //verify
            assertEquals(Calc.addPublicStatic(i, i), i);
        }


        //verify static
        PowerMockito.verifyStatic(times(6));
    }

8.测试私有成员变量
Powermock提供了一个Whitebox的class,可以方便的绕开权限限制,可以get/set private属性,实现注入。也可以调用private方法。也可以处理static的属性/方法,根据不同需求选择不同参数的方法即可。

@Test
public void testPrivateField() throws IllegalAccessException {
    PowerMockito.mockStatic(Calc.class);

    assertEquals(Whitebox.getField(Calc.class, "mPrivateField").getInt(mCalc), 0);
    assertEquals(Whitebox.getField(Calc.class, "mPrivateFinalField").getInt(mCalc), 0);
    assertEquals(Whitebox.getField(Calc.class, "mPrivateStaticField").getInt(null), 0);
    assertEquals(Whitebox.getField(Calc.class, "mPrivateStaticFinalField").getInt(null), 0);


    Whitebox.setInternalState(mCalc, "mPrivateField", 1);
    Whitebox.setInternalState(Calc.class, "mPrivateStaticField", 1, Calc.class);

    assertEquals(Whitebox.getField(Calc.class, "mPrivateField").getInt(mCalc), 1);
    assertEquals(Whitebox.getField(Calc.class, "mPrivateFinalField").getInt(mCalc), 0);
    assertEquals(Whitebox.getField(Calc.class, "mPrivateStaticField").getInt(null), 1);
    assertEquals(Whitebox.getField(Calc.class, "mPrivateStaticFinalField").getInt(null), 0);
}

9.测试私有成员方法

@Test
    public void testAddPrivateMethod() throws Exception {
        PowerMockito.mockStatic(Calc.class);

        //when
        PowerMockito.when(mCalc,"addPrivate",anyInt(),anyInt())
                .thenReturn(0)
                .thenReturn(1)
                .thenReturn(2)
                .thenReturn(3)
                .thenReturn(4)
                .thenReturn(5);

        //call method
        for (int i = 0; i < 6; i++) {

            //verify
            assertEquals(Whitebox.invokeMethod(mCalc,"addPrivate",i,i), i);
        }

        //verify static
        PowerMockito.verifyPrivate(mCalc,times(6)).invoke("addPrivate",anyInt(),anyInt());
        PowerMockito.verifyPrivate(mCalc,atLeast(1)).invoke("addPrivate",anyInt(),anyInt());
    }

10.测试私有静态成员方法

@Test
  public void testAddPrivateStaicMethod() throws Exception {
      PowerMockito.mockStatic(Calc.class);

      PowerMockito.when(Calc.class, "addPrivateStatic", anyInt(), anyInt())
              .thenReturn(0)
              .thenReturn(1)
              .thenReturn(2)
              .thenReturn(3)
              .thenReturn(4)
              .thenReturn(5);


      //call method
      for (int i = 0; i < 6; i++) {

          //verify
          assertEquals(Whitebox.invokeMethod(Calc.class,"addPrivateStatic",i, i), i);
      }


      //verify static
      PowerMockito.verifyStatic(times(6));
  }

通过以上介绍,相信你对Android项目的Mock单元测试有一定的了解。
如果你有任何相关疑问,请通过以下方式联系我:

Email:yanghui1986527#gmail.com
QQ 群: 529327615

参考

  1. 详细讲解单元测试的内容
  2. 浅谈单元测试的意义
  3. 敏捷开发之测试
  4. Unit testing support
  5. junit4
  6. mockito
  7. powermock
  8. mocktest
  9. 在Android Studio中进行单元测试和UI测试
  10. whats-the-best-mock-framework-for-java
  11. mock测试
  12. 使用PowerMock来Mock静态函数
  13. PowerMock介绍
  14. Sharing code between unit tests and instrumentation tests on Android
  15. Unit tests with Mockito - Tutorial
  16. Android单元测试之Mockito浅析
  17. Mockito 简明教程
  18. mockito简单教程
相关文章
|
26天前
|
Java 测试技术 开发者
必学!Spring Boot 单元测试、Mock 与 TestContainer 的高效使用技巧
【10月更文挑战第18天】 在现代软件开发中,单元测试是保证代码质量的重要手段。Spring Boot提供了强大的测试支持,使得编写和运行测试变得更加简单和高效。本文将深入探讨Spring Boot的单元测试、Mock技术以及TestContainer的高效使用技巧,帮助开发者提升测试效率和代码质量。
136 2
|
1月前
|
机器学习/深度学习 人工智能 监控
提升软件质量的关键路径:高效测试策略与实践在软件开发的宇宙中,每一行代码都如同星辰般璀璨,而将这些星辰编织成星系的过程,则依赖于严谨而高效的测试策略。本文将引领读者探索软件测试的奥秘,揭示如何通过精心设计的测试方案,不仅提升软件的性能与稳定性,还能加速产品上市的步伐,最终实现质量与效率的双重飞跃。
在软件工程的浩瀚星海中,测试不仅是发现缺陷的放大镜,更是保障软件质量的坚固防线。本文旨在探讨一种高效且创新的软件测试策略框架,它融合了传统方法的精髓与现代技术的突破,旨在为软件开发团队提供一套系统化、可执行性强的测试指引。我们将从测试规划的起点出发,沿着测试设计、执行、反馈再到持续优化的轨迹,逐步展开论述。每一步都强调实用性与前瞻性相结合,确保测试活动能够紧跟软件开发的步伐,及时适应变化,有效应对各种挑战。
|
17天前
|
Web App开发 定位技术 iOS开发
Playwright 是一个强大的工具,用于在各种浏览器上测试应用,并模拟真实设备如手机和平板。通过配置 `playwright.devices`,可以轻松模拟不同设备的用户代理、屏幕尺寸、视口等特性。此外,Playwright 还支持模拟地理位置、区域设置、时区、权限(如通知)和配色方案,使测试更加全面和真实。例如,可以在配置文件中设置全局的区域设置和时区,然后在特定测试中进行覆盖。同时,还可以动态更改地理位置和媒体类型,以适应不同的测试需求。
Playwright 是一个强大的工具,用于在各种浏览器上测试应用,并模拟真实设备如手机和平板。通过配置 `playwright.devices`,可以轻松模拟不同设备的用户代理、屏幕尺寸、视口等特性。此外,Playwright 还支持模拟地理位置、区域设置、时区、权限(如通知)和配色方案,使测试更加全面和真实。例如,可以在配置文件中设置全局的区域设置和时区,然后在特定测试中进行覆盖。同时,还可以动态更改地理位置和媒体类型,以适应不同的测试需求。
17 1
|
1月前
|
机器学习/深度学习 存储 测试技术
从0到1:如何规划一套流量回放自动化测试方案
本文介绍了流量回放自动化测试的完整方法,从企业战略到交付的四个关键环节:Discovery(深度挖掘)、Define(定义目标)、Design(详细设计)和Delivery(交付与反馈)。通过这些步骤,帮助企业优化系统性能和稳定性,确保产品的高质量。
54 4
|
1月前
|
存储 NoSQL 大数据
大数据-51 Redis 高可用方案CAP-AP 主从复制 一主一从 全量和增量同步 哨兵模式 docker-compose测试
大数据-51 Redis 高可用方案CAP-AP 主从复制 一主一从 全量和增量同步 哨兵模式 docker-compose测试
33 3
|
2月前
|
Java 测试技术 Android开发
Android性能测试——发现和定位内存泄露和卡顿
本文详细介绍了Android应用性能测试中的内存泄漏与卡顿问题及其解决方案。首先,文章描述了使用MAT工具定位内存泄漏的具体步骤,并通过实例展示了如何分析Histogram图表和Dominator Tree。接着,针对卡顿问题,文章探讨了其产生原因,并提供了多种测试方法,包括GPU呈现模式分析、FPS Meter软件测试、绘制圆点计数法及Android Studio自带的GPU监控功能。最后,文章给出了排查卡顿问题的四个方向,帮助开发者优化应用性能。
170 4
Android性能测试——发现和定位内存泄露和卡顿
|
2月前
|
测试技术 数据库连接 数据库
提升软件测试效率与灵活性:探索Mock测试的重要性
【9月更文挑战第20天】在软件测试领域,提升测试效率与灵活性至关重要。Mock 测试通过模拟外部组件,使模块能独立测试,缩短测试周期;快速反馈机制让测试结果即时可见,加速问题修复;还能模拟异常情况和进行参数化测试,增强测试全面性与灵活性,从而显著提高软件质量和开发效率。
|
2月前
|
测试技术 Shell Android开发
Android 性能测试初探 (六)
本节聊聊性能测试的最后一项- 流量,当然我所指的性能测试是针对大部分应用而言的,可能还有部分应用会关注网速、弱网之类的测试,但本系列文章都不去一一探讨了。
54 6
|
2月前
|
JavaScript 测试技术 Android开发
Android 性能测试初探 (四)
本文介绍了GPU在移动端性能测试中的重要性,并详细解释了过度绘制、帧率和帧方差的概念。针对GPU测试,文章列举了三项主要测试内容:界面过度绘制、屏幕滑动帧速率和平滑度。其中,过度绘制测试需遵循特定标准,而帧速率和平滑度测试则可通过软件或硬件方法实现。在软件测试中,使用Systrace插件和高速相机是两种常用手段。对于不同机型,帧率及帧方差的测试标准也需相应调整。
53 5
|
2月前
|
测试技术 Shell Android开发
Android 性能测试初探 (三)
本文承接《Android性能测试初探(二)》,深入探讨CPU与内存测试。介绍了移动端内存测试的重要性及其测试目标,并详细列举了不同状态下应用内存消耗情况的测试项目。此外,还提供了多种内存测试方法,包括使用`procrank`等工具的具体操作步骤。最后,文章也简要提及了CPU测试的相关内容,帮助读者更好地理解Android性能测试的关键要素。
52 5