Android使用Mockito和Roboletric进行单元测试

好的测试用例常常能让开发效率和质量大大提升，但是代码设计有时候会使测试用例无从下手、难以书写，神烦，很多时候会让开发者忽略做单元测试，又或干脆就懒得写了。在开源界也涌出了很多优秀的单元测试框架，就是为了弥补“单元测试不好写”这个缺陷:

• Mockito 强大的模拟工具，能够模拟出无关的依赖模块、行为，并能够验证调用顺序；

• Roboletric 在JVM上模拟Android测试环境（即通过单元测试就能测试部分Android代码）。

本文结合这两个库来介绍一下在Android开发中如何写单元测试。

为什么要单元测试？

在写单元测试的时候，你需要想明白这个问题，才能更有针对性地去写测试用例。

单元测试的好处体现在于：

1. 你做了一个很大的底层改动，跑一遍单元测试，哇，全通过了！测试通过让你有信心将代码发布出去；

2. 在写测试的时候你会对自己的代码进行思考，每一个操作应用后将会产生什么样的期望后果；

3. 在快速开发时，写几个单元测试保证代码质量。

就拿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来完成你需要的测试功能点。

原文链接：http://www.apkbus.com/blog-705730-61768.html