软件开发历史大潮中，我们做了许许多多的努力让代码变得更加优雅。但是「优雅」这一件事，并不是简单的让代码变得漂亮而已，我们的「优雅」是有目的的：
可维护、可扩展、可测试。从实用性角度来讲，我认为「可测试」这是我们在产品开发中追求的第一要素，毕竟质量是我们坚持的第一要素，没有质量背书，许多的工作都是空想。今天我们就来讲讲，如何通过Google新发布的Android Architecture Components去写我们的代码，使得我们的项目变得更加「Testable」。省长 | 19 min (4997 words)
软件开发历史大潮中，我们做了许许多多的努力让代码变得更加优雅。但是「优雅」这一件事，并不是简单的让代码变得漂亮而已，我们的「优雅」是有目的的：可维护、可扩展、可测试。从实用性角度来讲，我认为「可测试」这是我们在产品开发中追求的第一要素，毕竟质量是我们坚持的第一要素，没有质量背书，许多的工作都是空想。今天我们就来讲讲，如何通过Google新发布的Android Architecture Components去写我们的代码，使得我们的项目变得更加「Testable」。
写测试，在圈子里似乎并不是那么的流行，我曾经在几次聚会中问身边的 Android 开发：「你们会自己去写白盒测试么？」，回答都是否定的，如果再问为什么的话，就是「太麻烦了」、「不知道怎么写，不知道写什么」。当我们说 MVC/MVP 的时候，我们究竟是为了什么而实现这些模式的，我们为什么要为一些模块写大量的接口，仅仅是看上去酷炫？最后为了赶工期进度，胡乱写一通的时候，好像也没发生什么问题吧。那么这时候，其实写出来的所谓的「架构」其实并没有什么用处 ———— 当你去重构看起来烦的不行的业务代码的时候，依然需要花大量进行黑盒测试。开发说，架构不可以随便动，因为线上已经跑了很长时间了，至少证明了它暂时是可行的。
我们期望改变这样的状况，我们希望随时随地能真正把我们的产出掌握在自己手里 ———— 哪怕哪一天真的忘记了具体实现，哪怕新同事入职接手了这一份代码，我们也能胸有成竹的说，你随便跑，只用跑一下我写的测试，通过了就好。
首先我们能达成的共识是：我们的业务代码，很多都是和 UI 耦合在一起，很多都是和「生产环境」绑定在一起，所以我们的代码才变得非常的不可测试。我们使用分层架构模型，也只是为了一个目的：使得下层依赖的模块可替换。那么，基于我们所拥有的条件和所碰到的困难， 我们是否可以把我们的分层架构模型用于替换生产环境呢，这样就可以轻松测试我们的业务逻辑了？答案是肯定的。只要我们把我们的生产环境轻松的替换成我们 Mock 的数据环境，我们的「服务器」就变得可控了，我们可以返回我们期待的结果，看我们的后续业务逻辑流程是否处理正确。
同理，如果我们依赖的 View 层，只用统一的数据流和这一层通信的话，我们的测试只用控制这一个数据流，然后用 Espresoo 等 UI Test 框架去检查 UI 的反应是否正确即可。Android Architecture Components 提供了一套自顶向下的分层解决方案，很适合我们的场景，使得我们写测试变得更加的容易。
其实我更愿意称呼LiveData为「ViewModel」，如果你对react.js有了解，它更像是我们 Component 中的props概念。我们可以为 Activity 或者 Fragment（以下统称 View）提供多个 LiveData。在support-v4升级到27.0.0之后，AppCompatActivity已经自动集成了Lifecycle相关的接口和实现，LiveData本身使用「观察者模式」为View提供数据，如果View的生命周期销毁，那么它会自动解除注册，不需要我们在onStop或者onDestroy中去调用它的生命周期。我们可以使用LiveData彻底对 View 的配置进行解耦。View 层的代码大致就可以如下
class ExampleActivity extends AppCompatActivity {
@Inject
Presenter presenter;
TextView textView;
Button btn;
public void onCreate(Bundle savedBundle) {
Inject.inject(this);
super.onCreate(savedBundle);
// 一些初始化
...
// 初始化完毕
LiveData<String> textLive = presenter.getTextLive().observe(this, new Observer {
public void onChanged(String value) {
textView.setText(value);
}
})
btn.setOnClickListener(new OnClickListener() {
public void onClick(View v) {
presenter.fetchText();
}
});
}
}
123456789101112131415161718192021222324252627282930
那么 View 这层实际就干了两件事：
它的全部职责就是获取到真正的Presenter（业务实现），并处理好视图相关的所有事情。这样的模式比起以前的「万能 Activity」不知道清晰多少倍。那么如何对这个 View 进行测试呢？很显然，我们只要提供一个受我们控制的Presenter类即可，后续控制 Presenter 中的 LiveData，通过推送不同的数据，来观察我们的 View 各个字段显示是否正确，测试用的TestPresenter可以由Dagger等框架进行注入。
这里的 ViewModel 指的是 ViewModel 这个类的本身。它并不是我们传统理解的那个「ViewModel」，Google 在这是把他定义为存储 View 相关数据的，有生命周期意识的类 —— 它保证了在屏幕翻转等情况下，数据的存续。众所周知，Android 中四大组件的生命周期都不是由我们自己控制的，因此对一些对象的生命周期控制，有时候会显得非常蠢，试想一个场景：
你的一个 Activity 中，有两个 Fragment，他们共享某个共同的状态，不仅对这个状态产生一些响应，同时又都可以改变这个状态。也许其中一个 Fragment 还拥有一个子 Fragment，可能也会改变该状态。
这个场景下，我们想快速写出简单漂亮的代码几乎是不可能的事，那么使用「ViewModel」能让我们在 Activity 或者 Fragment 中获取一个准确的生命周期的内存缓存对象，其中可以存有我们需要的 LiveData，然后只要订阅了这个 LiveData，所有的 View 状态都会一致！
如果看一下ViewModel源码的话，你会发现，它的本质是在Activity或者Fragment中，生成一个看不见的Fragment ———— 也就是ViewProviders.of()这个函数传的第一个参数中。然后把 ViewModel 存入这个Fragment里，所有的变量的生命周期跟随这个隐藏的Fragment。
这么看下来，我更宁愿称呼这个ViewModel为Presenter，事实上我们内部项目也是这么命名的，它的职责就是和数据仓库打交道，然后把组装回来的数据通过LiveData post 到 View 层给开发者。
我们使用RxJava2来实现数据仓库，测试该层，我们首先可以使用Mockito来 mock 需要的 LiveData，然后使用MockServer或者其他的方式，获取我们期望的数据，然后看 LiveData 的行为是否和我们期望的一致（此处的测试更像是 BDD）。
我们期望把所有 IO（DB and Network）封装成 Repository 层供给 Presenter 去调用，表达形式是 Observable，Presenter 层完全不需要知道数据的存储形式是怎么样的，是缓存还是线上的数据，只需要从 Repository 去取就对了。对于这层的测试可以使用 okhttp 提供的MockWebServer组件去测试相关的代码行为。
如果你之前看过「Clean 架构」这个概念，那么你一定对这张图非常熟悉
事实上，我们的整个架构组织也是按照「Clean」的模式来的，在使用 Clean 的过程中，有一个原则非常重要，那就是单向数据流。为了保证逻辑的简单和统一，数据流的「单向」必须保证，必须可控，这和 flux 的世界观非常像：
如果有条件的话，非常建议可以看看 flux 相关的视频 https://facebook.github.io/flux/docs/in-depth-overview.html 加深理解。
做一次架构优化或者做一次架构设计前，我们一定要仔细考虑清楚我们的目的是什么，不能盲目的直接下手，否则我们根本无法对架构设计者的一些理念做出深刻的理解，可能只会徒增烦恼。在质量要求越来越高的当下，我们做出的产品一定是以质量为第一要义的，因此以上是我对Android Architecture Components在可测试领域上的思考。如果有任何的建议和意见，欢迎留言，欢迎指点。
PS：有赞共享移动技术岗位急缺 iOS / Android，最近有想法的同学快来我们的怀抱吧
岗位职责
我们不仅写测试，还写构建系统，还写 WebView 加速模块，还写 Xposed 等等各种好玩的等着你！ 简历速来 wenshengzhang@youzan.com
欢迎关注我们的公众号
