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

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

因为其模拟的虚拟机ÿ