Android 单元测试实战（1）—— 调研与选型

素颜马尾好姑娘i 2024-04-19 15:07 3阅读 0赞

## 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`测试，查询一个控件，模拟点击，验证逻辑。

因为其模拟的虚拟机，那么他对官方的方法做了扩展，提供了一些列的`ShadowXXX`类，便于做验证和模拟。比如获取当前弹出的`dialog`，最后一个弹出的`toast`等等。

调研的时候，该框架最新版本为`4.3`，并且从`4.0`开始，已经开始和官方的`androidx.test`下测试库进行兼容。可以通过官方`espresso`完成一些列操作。那么一套代码，技能在控制台运行，又能在模拟器上运行，想想还是挺美好的。

但是 ！！！

因为我们的项目都是在`Activity`里面写的，一些业务逻辑都是使用私有方法，那么相对私有方法做验证，通过查询控件和通过`UI`的展示来验证逻辑的正确与否，十分的复杂。

举个例子：

@Override
        public void onClick(View v) { 
            switch (v.getId()) { 
                case R.id.skip:
                    startNextActivity(false);
                    break;
                case R.id.splash_image:
                    startNextActivity(true);
                    break;
                default:
                    break;
            }
        }
        
        private synchronized void startNextActivity(boolean isClick) { }

我想验证不同的`View`点击，调用的`startNextActivity`的参数是否正确。如果从`UI`上验证十分的复杂，而且万一`startNextActivity`的内部逻辑有问题，或者比较巧妙，那么`UI`的验证也不一定准确。

有方法解决吗？？肯定有，便是`Mock`，这个后面会说。

能够`Mock`私有方法的常用的是`Powermock`，但是！！！！！

该框架和`Robolectric`存在着各种兼容问题，在我头发掉了一地之后，也没有解决。

所以放弃了！！！！注意是放弃了`Robolectric`！！！！

### Mock (使用) ###

`mock`是单元测试中常用的一种方式，通过对即将调用方法的修改，模拟调用方法的返回值等等，具体的概念百度上一大堆。我就不再这里废话了。

官方文档上建议使用`Mockito`完成`mock`操作，但是该库不支持静态方法，私有方法，`final`等的`mock`。

上面提到了`Powermock`，他提供更加强大的`mock`功能，而且它提供了`Mockito`的支持，使用上和`Mockito`基本上一样。

比如说，对于上面的代码，使用`Powermock`方法验证逻辑如下：

@Test
        public void onClickSkip() throws Exception { 
            // mock activity, activity的所有方法都不会被执行
            LauncherActivity activity = PowerMockito.mock(LauncherActivity.class);
            // 指定activity的onClick不被`mock，调用真实的逻辑，以便进行单元测试
            PowerMockito.doCallRealMethod().when(activity, "onClick", ArgumentMatchers.any(View.class));
    
    		 // Mock 官方类
            View view = PowerMockito.mock(View.class);
            // 指定getId的返回值
            PowerMockito.doReturn(R.id.skip).when(view, "getId");
    		 // 调用测试的方法 
            activity.onClick(view);
         	 // 验证指定的方法和参数是否被滴啊用 
            PowerMockito.verifyPrivate(activity).invoke("startNextActivity", false);
        }

代码注释很清楚，不在废话。

按照上面的思路，其实可以验证大部分的单元测试逻辑。

### 总结 ###

综上所述，决定使用`Powermock`为基础，完成单元测试的编写。