好的测试用例常常能让开发效率和质量大大提升，但是代码设计有时候会使测试用例无从下手、难以书写，神烦，很多时候会让开发者忽略做单元测试，又或干脆就懒得写了。在开源界也涌出了很多优秀的单元测试框架，就是为了弥补“单元测试不好写”这个缺陷:
Mockito 强大的模拟工具，能够模拟出无关的依赖模块、行为，并能够验证调用顺序；
Roboletric 在JVM上模拟Android测试环境（即通过单元测试就能测试部分Android代码）。
本文结合这两个库来介绍一下在Android开发中如何写单元测试。
为什么要单元测试？
在写单元测试的时候，你需要想明白这个问题，才能更有针对性地去写测试用例。
单元测试的好处体现在于：
你做了一个很大的底层改动，跑一遍单元测试，哇，全通过了！测试通过让你有信心将代码发布出去；
在写测试的时候你会对自己的代码进行思考，每一个操作应用后将会产生什么样的期望后果；
在快速开发时，写几个单元测试保证代码质量。
就拿Fresco里面的单元测试举个例子，它测试DraweeView在attach/detach到Window上时的反应：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | @Test public void testLifecycle_Controller() { InOrder inOrder = inOrder(mController); // 初始化mockito类，验证调用顺序 mDraweeView.setHierarchy(mDraweeHierarchy); mDraweeView.setController(mController); inOrder.verify(mController).setHierarchy(mDraweeHierarchy); // 是否调用了setHierarchy mDraweeView.onAttachedToWindow(); // 模拟View attachWindow 事件 inOrder.verify(mController).onAttach(); // 是否调用了 onAttach mDraweeView.onStartTemporaryDetach(); // 模拟View temporaryDetach 事件 inOrder.verify(mController).onDetach(); // 是否调用了 onDetach mDraweeView.onFinishTemporaryDetach(); // 模拟View finishTemporaryDetach 事件 inOrder.verify(mController).onAttach(); // 是否调用了 onAttach （结束临时detach，即应该重新attach） mDraweeView.onDetachedFromWindow(); // 模拟View detach 事件 inOrder.verify(mController).onDetach(); // 是否调用了 onDetach } |
上面这段测试用例很简单，但是功能很强大，它保证了这个DraweeView在View的attach/detach处理这个环节的代码正确。
StackOverflow上有个回答很棒，你只有开始写单元测试后才能体会到它的强大，那么我们来学习一下吧。
Mockito的作用
通常组件之间都会有模块化依赖，但是写单元测试时一般仅涉及一两个组件，若要复现操作环境是非常困难的事情。而Mockito能够轻易Mock一个依赖模块实例，并指定它的行为，把精力用在你想要的那一小个单元的测试。
1. Mock 模拟行为
这是它的精髓之一，可以通过注解@Mock(语法糖)或者Mockito.mock(Class<T> clazz)模拟出一个实例，传入的不论是Interface, Abstract class还是普通Class，统统都会mock出一个继承原类、填满hook的新类。注意这个生成的新类是一个空壳，如果需要使用必须指定行为（Stub）。对于未Stub的方法，通常返回null。我们可以写个test来验证一下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | class ExampleClass { public String test() { return "test"; } } //test class ExambleClassTest { @Mock ExampleClass mTestClass; @Before public void setUp() { MockitoAnnotations.initMocks(this); // 初始化被@Mock注解的类 } @Test public void testOrigin() { Assert.assertEquals("test", mTestClass.test()); // Fail } @Test public void testMock() { Mockito.when(mTestClass.test()).thenReturn("testMock"); Assert.assertEquals("testMock", mTestClass.test()); // Success } } |
上面这段测试用例中，testOrigin()会报失败，因为test()方法被hook后返回了null。testMock()会成功，因为我们把这个方法Stub住了，让它返回了”testMock”。
除了mock，还有另一种用法：@Spy/spy(Class<T> clazz)。它可以对一个类的实例（或者含有无参构造函数的类）进行模拟，未指定行为的方法由原类处理，指定行为的类由hook处理。对上面的ExampleClass，我们可以用Spy来进行一个测试：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | public class ExampleClassTest { @Spy ExampleClass mExampleClass; @Before public void setUp() { MockitoAnnotations.initMocks(this); } @Test public void testOrigin() { // Success Assert.assertEquals("test", mExampleClass.test()); } @Test public void testMockSpy() { // Success Mockito.doReturn("mockSpy").when(mExampleClass).test(); Assert.assertEquals("mockSpy", mExampleClass.test()); } } |
这里testOrigin()和testMockSpy()都会通过（注意在@Mock注释下testOrigin()会失败)，因为Spy只是部分Mock，对没有模拟行为的部分仍返回原结果，但是用起来也会不一样，具体看下文。
模拟行为（Stub）一共有两类做法：
Mockito.when(obj.methodCall()).thenReturn(result); 会检查返回类型；不可用于重复Stub、返回void的函数、Spy作用下mock类的call。
Mockito.doReturn(result).when(obj).methodCall(); 不会检查返回类型，可重复Stub
之所以说是两类做法，是因为里面的所有return都可以换成answer，不仅指定返回，还可以指定methodCall中做的事情：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | class CountClass { int count = 0; public void addCount() { count++; } } // 测试用例 class CountClassTest { @Mock CountClass mTestClass; @Before public void setUp() { MockitoAnnotations.initMocks(this); Mockito.doAnswer(new Answer<Void> { public Void answer(InvocationOnMock invocation) throws Throwable { mTestClass.count += 2; return null; } }).when(mTestClass).addCount(); } @Test public void testMockVoid() { // Success mTestClass.addCount(); Assert.assertEquals(2, mTestClass.count); } } |
ps: 如上调用是唯一一种Stub void返回函数的做法。
2. 验证行为
由于Mockito在mock出来的对象中四处都是hook，所以它可以做到一个很棒的功能：验证调用。基于上文的CountClass你可以写一个如下的简单测试：
1 2 3 4 5 6 7 | @Test public void testAddCount() throws Exception { mCountClass.addCount(); mCountClass.addCount(); Mockito.verify(mCountClass, new Times(2)).addCount(); Assert.assertEquals(4, mCountClass.count); } |
3. 题外话
when(obj.methodCall()).thenReturn(something)时这个方法到底有没有被执行呢？我感到很好奇。于是我试验了一下，发现它确实是被调用了，但是是无法用Mockito.verify验证到的。你可以跑一下如下测试:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | class TestClass { int count = 0; public String test() { return "test"; } } class TestClassTest { @Mock TestClass mTestClass; @Before public void setUp() { MockitoAnnotations.initMocks(this); } @Test public void testAddCount() { Mockito.when(mTestClass.addCount()).thenAnswer(ew Answer<String> { public String answer(InvocationOnMock invocation) throws Throwable { mTestClass.count += 2; return "test"; } }); Mockito.when(mTestClass.addCount()).thenAnswer(ew Answer<String> { //此处会调用一次第一次的Stub public String answer(InvocationOnMock invocation) throws Throwable { mTestClass.count += 2; return "test"; } }); Assert.assertEquals(2, mCountClass.count); // Success Mockito.verify(mTestClass).addCount(); // Fail } } |
Mockito.when(mTestClass.addCount()).thenAnswer() 这里一共有三步： mTestClass.addCount() -> when() -> thenAnswer()。
由于mTestClass.addCount()确实被调用了，所以它产生的后果是持久性的，所以后续验证mCountClass.count==2是对的。但是这里又蛮有意思的，为什么不会被verify？我去翻阅了一下源码，发现了两处相关代码，供大家理解：
3.1 MockHandlerImpl中处理函数调用：
这里就是所有的mock对象hook处理集中处，它是类似动态代理的处理。
1 2 3 4 5 6 7 8 9 10 | public Object handle(Invocation invocation) throws Throwable { // ... // 将此次调用设置为可能的Stub对象 invocationContainerImpl.setInvocationForPotentialStubbing(invocationMatcher); OngoingStubbingImpl<T> ongoingStubbing = new OngoingStubbingImpl<T>(invocationContainerImpl); mockingProgress.reportOngoingStubbing(ongoingStubbing); // 寻找是否有Stub的方法调用，有则调用，否则返回默认返回 } |
在setInvocationForPotentialStubbing(invocation)中它将此次调用添加到了一个LinkedList中。
3.2 OugoingStubbingImpl中添加Stub
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | // OutgoingStubbingImpl.java public OngoingStubbing<T> thenAnswer(Answer<?> answer) { // 如果没有可Stub的对象则报错 invocationContainerImpl.addAnswer(answer); // 将这个Answer设置为Stub返回，并且移除上一个调用记录(肯定是被Stub的函数调用)。 return new ConsecutiveStubbing<T>(invocationContainerImpl); } // InvocationContainerImpl.java public void addAnswer(Answer answer) { registeredInvocations.removeLast(); addAnswer(answer, false); } |
这里将调用记录，也就是后续verify的时候检查的东西抹去了！
所以说Mocktio.when(obj.methodCall()).thenAnswer(answer)在重复Stub的时候是存在问题的，虽然不会被verify到，但如果Stub的Answer中做了一些持久改变，它会在下次被Stub时的那次调用中生效。多次Stub可以用Mocktio.doReturn(something).when(obj).methodCall()，这里它在真实的调用之前已经将Stub替换掉了，所以不会出现这个问题。
Roboletric能做的事
Roboletric是另一个优秀的库，它的目标是你能够用单元测试来测试一些Android相关的代码。正常情况下跟Activity、Service有关的测试需要走Instrument测试，在实机上跑，然而Robolectric可以让你轻松地在电脑上就跑起Android测试。
Robolectric使用了自己的ClassLoader，它在UnitTest运行时插入了各类Shadow Object来为Android原生类添加一些hook用于测试。RobolectricTestRunner会从它上传的org.robolectric:android-all里面去拿对应的Android SDK。这个原理比较复杂，先不深究了，主要看看用法吧：
1. 基础用法
首先你有一个MainActivity，它含有R.id.root_view的一个根View，里面有一个Button点击可以跳转SecondActivity。你可以通过以下这段代码来让你的Activity走一遍onCreate->onStart->onResume，并做一些检查：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | @RunWith(RobolectricGradleTestRunner.class) @Config(constants = BuildConfig.class, sdk = 21) public class MainActivityTest { ActivityController<MainActivity> mActivityController; @Before public void setup(){ mActivityController = Robolectric.buildActivity(MainActivity.class).create().start().resume().visible(); } @Test public void testBase() { Assert.assertTrue(Shadows.shadowOf(mActivityController.get()).isTaskRoot()); //是否MainActivity在Task root ViewGroup view = (ViewGroup) mActivityController.get().findViewById(R.id.root_view); Assert.assertNotNull(view); // 是否存在view ShadowView shadow = Shadows.shadowOf(view); Assert.assertTrue(shadow.isAttachedToWindow()); // 是否已经attachToWindow TextView textView = new TextView(mActivityController.get()); view.addView(textView); Assert.assertTrue(shadow.didRequestLayout()); // 是否调用了requestLayout } @Test public void testButton() { Button btn = (Button) mActivityController.get().findViewById(R.id.button); Assert.assertNotNull(btn); btn.performClick(); ShadowActivity shadowActivity = Shadows.shadowOf(mActivityController.get()); Intent intent = new Intent(mActivityController.get(), SecondActivity.class); Assert.assertEquals(shadowActivity.getNextStartedActivity().getComponent(), intent.getComponent()); } } |
这里有几点注意：
使用@RunWith(RobolectricGradleTestRunner.class)时需要指定@Config(constants = BuildConfig.class)，它会从/build/intermediates/目录下找到merge的Manifest、Resource、Asset目录并加载。如果使用@RunWith(RobolectricTestRunner.class)则需要手动指定@Config(manifest = "...", resourceDir = "...", assetDir = "...")，manifest设置的目录base于Unit Test Config里面的”Working Directory”（见下图）
其他值resourceDir、assetDir的目录Base于manifest的父目录。
visible() 可能会令你感到困惑，因为它不属于Activity生命周期之一，但是执行visibile()会保证Activity的到Window上（包括初始化DecorView + add到WindowManager），否则findViewById()、attachToWindow等都会有问题。
关于MultiDex
Robolectric是在JVM上运行代码，根本没有”MultiDex”这回事，如果你的项目里用到了它，需要额外加入一个依赖:
testCompile "org.robolectric:shadows-multidex:${robolectricVersion}"
它hook了MultiDex这个类，让它在install的时候啥也不干。
2. 进阶使用：各类Shadow
Shadow是Robolectric里面的Hook类前缀，你可以利用Shadow得到一些Android组件无法获取到的状态，因为有的属性没有变量维护/没有public getter，又或无法获取上次操作结果，这时候就可以使用Shadow来定制一些需要的属性保存，看下面这个例子：
你的Activity里面有一个View(R.id.view), 它将OnClickListener设置为了Activity自身，在点击时会发一个广播(action=”com.desmond.androidtest.TestBroadcast”)，我们想验证这个情况。但是有两个问题：
View无法获取到OnClickListener，只能知道hasOnClickListener()；
Receiver不是你定义的，你只负责发，你如果需要验证需要自己额外注册一个Receiver，并编译运行检查是否成功。
使用Robolectric，你可以写下这么一个测试：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 | @RunWith(RobolectricGradleTestRunner.class) @Config(constants = BuildConfig.class, sdk = 21) public class MainActivityTest { ActivityController<MainActivity> mActivityController; @Before public void setup(){ mActivityController = Robolectric.buildActivity(MainActivity.class).create().start().resume().visible(); } @Test public void testBase() { View view = mActivityController.get().findViewById(R.id.view); Assert.assertNotNull(view); // 是否存在view ShadowView shadow = Shadows.shadowOf(view); Assert.assertEquals(shadow.getOnClickListener(), mActivityController.get()); // 是否已经attachToWindow view.performClick(); ShadowActivity shadowActivity = Shadows.shadowOf(mActivityController.get()); Intent expectedIntent = new Intent("com.desmond.androidtest.TestBroadcast"); List<Intent> intentList = shadowActivity.getBroadcastIntents(); // 获取发出的Broadcast boolean hasIntentSend = false; for (Intent i : intentList) { if(i.getAction().equals(expectedIntent.getAction())) { hasIntentSend = true; break; } } Assert.assertTrue(hasIntentSend); // 是否发出指定Broadcast } } |
很有意思吧，更多的”Shadow”可以在Shadows这个类里面找着，用的时候直接Shadows.shadowOf(object)就可以返回对应Shadow实例。你还可以自定义Shadow来完成你需要的测试功能点。