3.1 Android单元测试难点

在Android应用程序里写单元测试时，刚开始往往会有无从下手的感觉。他既有处理UI逻辑的代码，也有处理业务逻辑的代码，总感觉一团乱麻。根据个人的经验总结起来，本人觉得主要难点有以下几条：

1. Activity类充当了god class（上帝类），它接管了所有的职责，各种业务逻辑错综复杂的穿插在一起。业务逻辑之间没有一个清晰的边界，也就无法划分出“单元”。
2. 针对UI层面的单元测试，业界没有统一的标准，不知该如何下手。
3. Android默认的测试框架，必须运行在Android环境上，而这样会导致每次写单元测试时，都需要打包运行，才能进行测试。如果你的项目工程很大，打包的时间会很长，这样为了跑一个单元测试得花费老半天时间。
4. 我们来测试某一个方法时，有时会发现，这个方法里某个地方会依赖一个很重的对象来处理某个业务逻辑，而这个重对象的构造确很复杂，这样也会造成写单元测试的困难。

总的说来，造成单元测试很难写的原因：一方面是程序架构的问题，业务逻辑分层不清晰，职责不单一；另一方面是没有一个好的测试框架，有好的工具才会事半功倍。

3.2 如何解决单元测试难点

针对这些问题，我们一一来分析，该采用什么样的架构设计，以及采用什么样的测试框架，能解决我们写单元测试的难点。

1. 以前的Android应用程序，都是采用传统的MVC开发模式。MVC模式共分为3层：Model层、Controller层、View层，三层之间代码通常会耦合严重，彼此之间存在严重的依赖关系，这其实违反了软件设计高内聚、低耦合的原则。我们期待的是能够对每一层都能进行单独测试，层与层之间没有那么多的彼此依赖。由此，在MVC的基础之上演化出了MVP设计模式(不懂的自行搜索学习)，UI与业务逻辑完全隔离开来，这样就可以单独针对P层来测试，也可单独针对Model层来测试。
2. UI层的单元测试，现在谷歌提供了一个默认的测试框架Espresso+AndroidJUnitRunner，应该说官方提供的这个测试框架一定程度上解决了UI测试难的问题。
3. 打包慢是大家都会碰到的问题，我们期望的是有这么一个测试环境：当我们写好单元测试代码，能不能直接运行在JVM环境上，就像运行一个java类里面的main方法一样那么简单，不用每次都要打包那么麻烦而且缓慢。很早就有了JUnit这么一个测试框架，它只能运行纯java代码，但是我们的代码里面会用到很多Android SDK的东西，这样JUnit就不能完全满足我们的需求了。幸运的是，我们有了Robolectric单元测试框架，它实现了一套JVM能运行的Android代码，一定程度上做到了脱离Android环境进行测试。
4. 单元测试是针对某个方法来写的，如果这个方法里依赖了一个很重的对象（构造这个对象很复杂），那我们该怎么办呢。同样幸运的是，我们有Mockito这个测试神器。我们可以使用Mockito这么一个测试框架，对这些及其复杂的对象，mock一个出来，mock出来的对象具备了与原来对象一模一样的功能，这样就解决了这个问题。

3.3 测试方案

最终我选择的测试方案如下图所示：

测试框架.png

Presenter层仅仅处理业务逻辑，不需要处理UI等，所以我选择了直接运行在JVM环境上的框架；View层都是UI相关的东西，这个没的选择；Model层有2种选择，一种类似于数据库存储、SharePreference数据读取，它必须运行在Android环境上才方便测试，一种类似于Restfull Api接口请求之类的，它在JVM环境上是可以直接运行的，所以这里我选择了2种框架，具体根据实际情况来选择。

3.4 小结

本文先总结了Android单元测试的几个难点，接着针对这几个难点一一分析怎么去解决它们，最后确定了Android单元测试的整体测试方案，主要是不同情况下不同单元测试框架的选择。

系列文章：