[开发测试]Android单元测试 -＞知识整理及分享

Android单元测试

单元测试？

What？

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

Why？

1. 提高信心

单元测试不能百分之百保证在集成联调时能够完全正确运行，但可以保证每一代码单元测试通过。

1. 方便代码重构

使用单元测试可以边重构边写单元测试，保证重构没有破坏原有的代码逻辑的准确性。

1. 写单元测试本身就是一次小范围的代码重构

这个过程中，可以发现逻辑设计上的问题，代码编写方面的问题，比如一些边界条件处理、空对象的保护和类构造时参数的依赖问题，还有一些对Android Context的依赖问题。

1. 节约开发时间

如果没有单元测试的话，我们coding时为了调试某个功能，看界面是否显示正确，把APP运行起来，如果有错的话，改一点东西，再运行起来。。。有了单元测试，开发过程中可以更少的把APP运行起来，一两分钟的等待就可以验证代码逻辑是否正确，速度相对来说快很多。此外，通过单元测试能帮我们减少bug，从而减少了调试bug和fix bug的时间

1. 更快的发现bug

如果没有单元测试，我们就需要在最后的集成联调中才能发现自己模块的问题，一旦问题比较严重的话，可能会让自己感觉有压力和恐慌。但是通过单元测试，可以有多一层的保证，可以更早的发现问题和解决问题，在集成时让自己更加闲庭信步。

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

1. JUnit4

   1. 测试对象及环境：针对 无复杂依赖情况；针对 非私有、非静态、非全局的方法、类的测试；
   2. 用的最多的一个测试框架，Android Studio创建的工程中就默认集成了JUnit4，并添加了dependencies；
   3. 对应的单元测试代码则是放在src/test/java目录中，
   4. 编写：与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：通过断言检测结果

}

1. 运行：选中方法，右键 run 即可；

2. 主要测试对象

   1. 有明确的返回值；做单元测试时，只需调用这个函数，验证其返回值是否符合预期结果。
   2. 这个函数只改变其对象内部的一些属性或者状态，函数本身没有返回值，就验证它所改变的属性和状态。
   3. 一些函数没有返回值，也没有直接改变哪个值的状态，这就需要验证其行为，比如点击事件。???
   4. 对于 b、c 两种情况，往往是验证目标方法中的某个对象的某个方法是否得到了调用，或者验证目标方法中的某个对象的某个状态是否发生改变，以此来验证目标方法是否按照我们想要的逻辑进行调用；

3. 问题：对于项目中依赖资源复杂情况，处理困难；对于对象、集合、Map等数据结构的比较（断言的可读性不友好），可使用Hamcest框架进行比较；

4. Mockito

   1. 测试对象及环境：针对 复杂依赖情况；针对 非私有、非静态、非全局的方法、类的测试；

   2. 在测试环境中，通过Mockito mock出其他的依赖对象，用来替换真实的对象，使得待测的目标方法被隔离起来，

      避免外界因素的影响和依赖

      ，能在我们预设的环境中执行，以达到两个目的：

      1. 验证指定方法的调用情况，调用了多少次，参数是什么等等;
      2. 指定该对象的某些方法的行为，返回特定的值，或是执行特定的动作；

   3. 问题：生成mock对象的原理有其局限性，如final类型、private类型以及静态类型的方法不能mock；

5. PowerMockito

   1. 测试对象及环境：针对 复杂依赖情况；针对 私有、静态、全局的方法、类的测试；
   2. 扩展了其它mock框架；PowerMock基本上 cover 了 Mockito 不能支持的 case；
   3. 使用JUnit4+Mockito+PowerMockito可完成大部分java测试
   4. Powermock提供了mock和spy两种方式，对于 Activity 的私有方法的调用验证通常需要做方法模拟。mock 和 spy 都可以实现。
   5. 问题：对于依赖 Android SDK 的对象（如Activity，Button等），测试非常头疼；

6. Robolectric

   1. 测试对象及环境：针对 依赖 Android SDK 的对象（如Activity，Button等）的测试
   2. 通过实现一套JVM能运行的Android代码，从而做到脱离Android环境进行测试。
   3. 可实现UI测试，查询一个控件，模拟点击，验证逻辑；
   4. JUnit4+Mockito+PowerMockito+Robolectric
   5. 问题：因为我们的项目都是在Activity里面写的，一些业务逻辑都是使用私有方法，那么相对私有方法做验证，通过查询控件和通过UI的展示来验证逻辑的正确与否，十分的复杂。需要使用Powermock。
   6. 注意：Powermock和Robolectric存在着兼容问题，如果出现问题无法解决，可尝试放弃Robolectric

7. UIAutomator和Espresso；

Google开源的测试框架，基于Instrumentation，更偏向于UI方面的自测化测试。

Espresso功能强大、执行速度很快的，但是它有一个重要的局限：只可以在被测App的Context中操作。意味着下列App自动化测试需求无法实现：应用的推送消息、同步联系人、从另一个应用程序进入被测App。

UIAutomator 2.0 发布后可以实现上述功能；采用脚本语言编写，集成失败…UIAutomator集成测试失败；

1. robotium；UI测试用例

2. ActivityUnitTestCase、ActivityInstrumentationTestCase2

由Android提供的Instrumentation系统如，将单元测试代码运行在模拟器或者是真机上。虽然这种方式可以work，但是速度非常慢。

二、确定Android 测试框架

JUnit4 + Mockito + PowerMockito + Robolectric

使用：JUnit4 + PowerMockito

三、单元测试怎么写，非界面的逻辑部分的单元测试怎么写

在Android studio project中，源代码默认放在src/main/java下面的，

对应的Java相关的单元测试代码则是放在src/test/java目录中；

src/androidTest/java中存放的是Android相关的单元测试代码

1. JUnit4

依赖：默认是有的：testImplementation “junit:junit:$junit_version”

以 tosee-sdk 为例；src/main/java/tech/tosee/combine/models/TSPeer.kt

1. 单元测试
2. 非界面的单元测试

• 创建测试类。右键类名，选择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

1. 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, ...}) //声明多个静态类

1. 普通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))

    }

}

1. Mock 方法内部new出来的对象

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

• 待测代码 1

class CommonExampleKotlin {

    /**

     * 2) 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("测试失败.");

        }

    }

}

1. Mock普通对象的 final 方法

• 待测代码

class CommonDependency {

    /**

     * 3) 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'

4. Mock静态类的静态方法

• 待测代码

class CommonExampleKotlin {

    /**

     * 4) 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()))

    }

}

1. Mock 私有方法

• 待测方法

class CommonExampleKotlin {

    /**

     * 5) 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`<Boolean>(mock, "isExist").thenReturn(true)

        print(mock.callPrivateMethod())

        assertTrue(mock.callPrivateMethod())

    }

}

6. Mock系统类的静态和final方法

• 待测代码

class CommonExampleKotlin {

    /**

     * 6) 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`<String>(System.getProperty("aaa")).thenReturn("bbb");

        assertEquals("bbb", commonExample.callSystemStaticMethod("aaa"));

    }

}

7. Mock普通类的私有变量

• 待测代码

class CommonExampleKotlin {

    /**

     * 7) 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并注入你预设的变量值。

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

1. 概念：

程序中源代码被测试的比例和程度，所得比例称为代码覆盖率。

2. 指标

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

3. 使用方法

• 点击 IDE 上侧的"Edit Configurations…"：

• 在"Choose coverage runner"中选择JaCoCo：

• 运行；右键类名，选择 run ‘…’ with Coverage

• 运行完成后会展示 类（Classes）、方法（Methods）、行（Lines）等指标

• 点击左边栏 “Generate Coverage Report” 可以生成一份html版的所有指标的报告：
  

1. 参考文档

   1. Android单元测试框架-设计思路

   2. Jacoco：与Powermock有兼容性问题。

   3. Cobertra：

   4. Android 使用 JaCoco 分析单元代码测试覆盖率

   5. Android单元测试/Ui测试+JaCoCo覆盖率统计

   6. Android UI自动化测试的代码覆盖率

附：

1. ExoPlayer
   1. 是构建在Android低水平媒体API之上的一个应用层媒体播放器;
   2. ExoPlayer简单使用
   3. 官方文档
   4. ExoPlayer详解——入门（官方文档）
2. 圈复杂度
3. 其他方向
   

如有侵权，请联系删帖。

推荐阅读：
Mockito&PowerMockito的原理与使用
Java单元测试技巧之PowerMock
史上最轻量?！阿里新型单元测试Mock工具开源了

注意

1. 不必写每一个方法的测试方法；可以自己写@Test 类，而后在其内调用多个方法；——思路打开
2. 写好单元测试