Android context类是所有做个Android开发的应该都非常熟悉，就像一个百宝箱，能提供各种系统资源和服务，相当于给应用代码提供了运行所需的各种基础资源。所以在代码开发过程中，不可避免的传递到了各个环节，各个类。这样编码的时候是非常方便，但是如果要写测试代码的时候就出现了很多问题。
- 如果对象中出现了Context，那么就意味这这个对象的测试需要用AndroidTest来运行，需要编译成apk在手机中运行，apk的编译，安装，运行的时间就会非常长，虽然Google想了很多方法来降低这个时间，但是是unit test相比，还是长了很多，这对于要求快速反馈的单元测试来讲，还是不可接受。
- 没办法解耦，要测试逻辑代码，就需要mock平台和UI的各种情况，但是如果在实际环境中运行，就很难通过Mockito等各种mock工具方便的完成测试。
3.业务逻辑和UI，平台相关的逻辑混合，造成自动化测试很难实现，效率低下，因为代码中最核心的就是业务逻辑代码，而且相对来说更容易出错，而平台UI代码，逻辑比较简单，但是为了测试业务逻辑，就得考虑平台和UI代码，给编写测试代码造成了非常大的困难。而且UI的变化，就会造成测试用例的失效。
那么怎么来提升代码的可测试性呢。
首先，从架构入手，采用clear.或者六边形等洋葱圈式架构和 MVP，MVC，MVVM等设计模式，让平台UI代码依赖业务逻辑代码，做好平台代码，UI和业务逻辑代码的解耦。
其次，通过接口抽象和依赖倒置原则，分离业务代码和平台框架。比如要实现一个Android Service来做一个服务，可以通过把具体的业务代码放到一个 serviceImpl类里面，在这个类里面实现具体的业务功能，而把和平台相关的服务绑定，启动，初始化等放到Service类里面。
最后 通过依赖注入，把平台代码模块和业务代码模块耦合。比如Android 平台上的 Dagger依赖注入库，或者最简单的通过构造函数传参或者set的方式实现简单的依赖注入。比如需要饮用平台的定时器功能，而定时器需要通过Context对象调用系统服务，因此可以通过定义一个ITimer的接口，在里面定义startTimer的接口和回调，或者对象的事件，然后让业务代码依赖这个接口，而实现一个Timer的类，封装平台的定时器服务，通过依赖注入的方式，注入到业务代码中。
最终实现在逻辑代码中彻底去掉去context对象的依赖。这样就可以很方便的对业务逻辑代码进行单元测试和功能测试。
手机码字，不方便写代码，等方便了再补充代码。
