用Robolectric来做Android unit testing

作为一只本科非计算机专业的程序猿,手动写单元测试是我从来没接触过的东西,甚至在几个月前,我都不知道单元测试是什么东西。倒不是说没听过这个词,也不是不知道它的大概是什么东西——“用来测试一个方法,或者是一小块代码的测试代码”。然而真正是怎么做的?我并没有一个概念,或者说并没有一个感觉。

记得第一份工作在创新工场的时候,听当时的boss @王明礼 说,公司有个神级的程序员(。。。名字忘了。。。),他会写大量的单元测试,甚至50%以上的代码都是单元测试。当时崇拜之极,却仍然觉得写单元测试是很麻烦的一件事情。

扯远了,话说回来,当你接触多了国外的技术博客,视频之后,你会发现,单元测试甚至TDD,在国外是非常流行的事情。很多人甚至说离开了单元测试,他们便没有办法写代码。这些都让我对单元测试的好感度逐渐的上升。然而,真正让我下定决心,一定要研究一下这个东西的,是前段时间看大名鼎鼎的《重构:改善现有代码的艺术》里面的一段话:

I've found that writing good tests greatly speeds my programming, even if I'm not refactoring. This was a surprise for me, and it is counterintuitive for many programmers...

--Martin Fowler 《Refactoring: Improving the Design of Existing Code》

是的,你没看错,他说单元测试可以节约时间,提高开发速度!!!身为一个无可救药的懒癌患者,看了这句话简直就像看到了一道神光似的!既然都可以节省时间,那肯定是要看看的啊!

有趣的是,Martin Fowler在《重构》里面说他最初是因为 Dave Thomas说的一句话,让他走上了单元测试的不归路。而我这几天刚好又在看Dave Thomas写的《Programming Ruby 1.9 & 2.0》,也算是个巧合啊!

Martin Fowler在《重构》里面还解释了为什么单元测试可以节省时间,大意是我们写程序的时候,其实大部分时间不是花在写代码上面,而是花在debug上面,是花在找出问题到底出在哪上面,而单元测试可以最快的发现你的新代码哪里不work,这样你就可以很快的定位到问题所在,然后给以及时的解决,这也可以在很大程度上防止regression(相信QE和QA们一定很喜欢哈哈。。。),这也是个大部分程序员和测试都很痛恨的问题。

之后不久,就开始花了点时间了解了一下Android里面怎么做unit testing,结果却发现那是个非常难办的事情。。。

### 为什么android unit testing不好做

我们知道安卓的app需要运行在delvik上面,我们开发Android app是在JVM上面,在开发之前我们需要下载各个API-level的SDK的,下载的每个SDK都有一个android.jar的包,这些可以在你的android_sdk_home/platforms/下面看到。当我们开发一个项目的时候,我们需要指定一个API-level,其实就是将对应的android.jar 加到这个项目的build path里面去。这样我们的项目就可以编译打包了。然而现在的问题是,我们的代码必须运行在emulator或者是device上面,说白了,就是我们的IDE和SDK只提供了开发和编译一个项目的环境,并没有提供运行这个项目的环境,原因是因为android.jar里面的class实现是不完整的,它们只是一些stub,如果你打开android.jar下面的代码去看看,你会发现所有的方法都只有一行实现:

throw RuntimeException("stub!!");

而运行unit test,说白了还是个运行的过程,所以如果你的unit test代码里面有android相关的代码的话,那运行的时候将会抛出RuntimeException("stub!!")。为了解决这个问题,现在业界提出了很多不同的程序架构,比如MVP、MVVM等等,这些架构的优势之一,就是将其中一层抽出来,变成pure Java实现,这样做unit testing就不会遇到上面这个问题了,因为其中没有android相关的代码。

好奇的童鞋可能会问了,既然android.jar的实现是不完整的,那为什么我们可以编译这个项目呢?那是因为编译代码的过程并没有真正的运行这些代码,它只会检查你的接口有没有定义,以及其他的一些语法是不是正确。举个简单的例子:

public class Test {
    public static void main(String[] argv) {
        testMethod();
    }
    public static void testMethod() {
        throw RuntimeException("stub!!");
    }
}

上面的代码你同样可以编译通过,但你运行的时候,就会抛出异常RuntimeException("stub!!")。当我们的项目运行在emulator或者是device上面的时候,android.jar被替换成了emulator或者是device上面的系统的实现,那上面的实现是真正实现了那些方法的,所以运行起来没有问题。

话说回来,MVP、MVVM这些架构模式虽然解决了部分问题,可以测试项目中不含android相关的类的代码,然而一个项目中还是有很大部分是android相关的代码的,所以上面那种解决方案,其实是放弃了其中一大块代码的unit test。

当然,话说回来,android还是提供了他自己的testing framework,叫instrumentation,但是这套框架还是绕不开刚刚提到的问题,他们必须跑在emulator或者是device上面。这是个很慢的过程,因为要打包、dexing、上传到机器、运行起来界面。。。这个相信大家都有体会,尤其是项目大了以后,运行一次甚至需要一两分钟,项目小的话至少也要十几秒或几十秒。以这个速度是没有办法做unit test的。

那么怎么样即可以给android相关的代码做测试,又可以很快的运行这些测试呢?

### Robolectric to the rescue

解决的办法就是使用一个开源的framework,叫robolectric,他们的做法是通过实现一套JVM能运行的Android代码,然后在unit test运行的时候去截取android相关的代码调用,然后转到他们的他们实现的代码去执行这个调用的过程。举个例子说明一下,比如android里面有个类叫TextView,他们实现了一个类叫ShadowTextView。这个类基本上实现了TextView的所有公共接口,假设你在unit test里面写到

String text = textView.getText().toString();。在这个unit test运行的时候,Robolectric会自动判断你调用了Android相关的代码textView.getText(),然后这个调用过程在底层截取了,转到ShadowTextViewgetText实现。而ShadowTextView是真正实现了getText这个方法的,所以这个过程便可以正常执行。

除了实现Android里面的类的现有接口,Robolectric还做了另外一件事情,极大地方便了unit testing的工作。那就是他们给每个Shadow类额外增加了很多接口,可以读取对应的Android类的一些状态。比如我们知道ImageView有一个方法叫setImageResource(resourceId),然而并没有一个对应的getter方法叫getImageResourceId(),这样你是没有办法测试这个ImageView是不是显示了你想要的image。而在Robolectric实现的对应的ShadowImageView里面,则提供了getImageResourceId()这个接口。你可以用来测试它是不是正确的显示了你想要的Image.

### Talk is cheap. Show me the code!

下面简单的介绍一下使用Robolectric来做unit testing。注意:下面的配置方法指的是AndroidStudio上面的,Eclipse用户自行google一下配制方法。

要使用Robolectric,需要做几步配置工作。

1. 首先需要将它和JUnit4加到你项目的dependencies里面,

testCompile 'junit:junit:4.12'
testCompile ’org.robolectric:robolectric:3.0-rc3’

其中的Robolectric的最新版本号可能会变,具体可以上jcenter查看一下当前的最新版本号。

2. 将Build Variant里面的Test Artifact选择为Unit Test,如果你找不到Build Variant,可以在菜单栏选择View -> Tool Windows -> Build Variant. 正常情况下它会出现在左下角。

3. 如果是Mac的话,还需要配置一个东西,菜单栏选择 Run -> Edit Configuration -> Defaults -> JUnit,在Configuration tab将working directory改成$MODULE_DIR$。这个配置是Robolectric官方文档提到的,但我用最新的AndroidStudio1.3实验的时候,忘了配置这个,貌似也可以正确运行,anyway,配置一下也无所谓。具体见Robolectric的官方文档,最下面那部分。

到这里,就可以开始code了。

测试代码是放在app/src/test下面的,test class的位置最好跟target class的位置对应,比如MainActivity放在

app/src/main/java/com/domain/appname/MainActivity.java

那么对应的test class MainActivityTest最好放在

app/src/test/java/com/domain/appname/MainActivityTest.java

这里举个简单又稍微有点用的例子,假设app里面有两个Activity:MainActivitySecondActivityMainActivity里面有一个TextView,点击一下这个TextView将跳转到SecondActivityMainActivity里面的代码大概如下:

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        TextView textView = (TextView)findViewById(R.id.textView1);
        textView.setOnClickListener(new OnClickListener() {
            @Override
            public void onClick(View v) {
                startActivity(new Intent(MainActivity.this, SecondActivity.class));
            }
        });
    }
}

对应的测试类,MainActivityTest的代码:

@RunWith(RobolectricGradleTestRunner.class)
@Config(constants = BuildConfig.class, sdk = 21)
public class MainActivityTest {
    @Test
    public void testMainActivity() {
        MainActivity mainActivity = Robolectric.setupActivity(MainActivity.class);
        mainActivity.findViewById(R.id.textView1).performClick();
        Intent expectedIntent = new Intent(mainActivity, SecondActivity.class);
        ShadowActivity shadowActivity = Shadows.shadowOf(mainActivity);
        Intent actualIntent = shadowActivity.getNextStartedActivity();
        Assert.assertEquals(expectedIntent, actualIntent);
    }
}

上面的代码测试的就是当用户点击textView的时候,程序会正确的跳转到SecondActivity。其中@RunWith(RobolectricGradleTestRunner.class)表示用Robolectric的TestRunner来跑这些test,这就是为什么Robolectric可以检测到你调用了Android相关的类,然后截取这些调用,转到他们的Shadow类的原因。此外,@Config用来配置一些东西。

代码中的

MainActivity mainActivity = Robolectric.setupActivity(MainActivity.class);用来创建MainActivity的instance,或者说,用来启动这个Activity,当Robolectric.setupActivity返回的时候,这个Activity已经完成了onCreate、onStart、onResume这几个生命周期的回调了。

mainActivity.findViewById(R.id.textView1).performClick();用来触发点击事件。ShadowActivity shadowActivity = Shadows.shadowOf(mainActivity);用来获取mainActivity对应的ShadowActivity的instance。

shadowActivity.getNextStartedActivity();用来获取mainActivity调用的startActivity的intent。这也是正常的Activity类里面不具有的一个接口。

最后,调用Assert.assertEquals来assert启动的intent是我们期望的intent。

运行这个unit test,启动命令行,cd到项目的根目录,运行

./gradlew test ,几秒钟后,你将看到测试运行的结果

...
:app:processDebugJavaRes UP-TO-DATE
:app:compileDebugJava UP-TO-DATE
:app:preCompileDebugUnitTestJava
:app:preDebugUnitTestBuild UP-TO-DATE
:app:prepareDebugUnitTestDependencies
:app:processDebugUnitTestJavaRes UP-TO-DATE
:app:compileDebugUnitTestJava
:app:compileDebugUnitTestSources
:app:mockableAndroidJar UP-TO-DATE
:app:assembleDebugUnitTest
:app:testDebug
BUILD SUCCESSFUL
Total time: 12.884 secs

在我的机器上(MacBook Air 2013款,8G内存,算比较低的配置),运行这个test只需要不到12秒钟,如果直接在AndroidStudio里面运行的话,这个速度会更快,一般可以再10秒之内完成,或许没有达到普通JUnit的秒级速度,然而相对于用Instrumentation来说已经是极大的提升了。
注:第一次运行可能需要下载一些library,或者是gradle本身,可能需要花一点时间,这个跟unit test本身没关。

整个项目已经放到github上面:robolectric-demo

### 小结

总体来说,Robolectric是个非常强大好用的unit testing framework。虽然使用的过程中肯定也会遇到问题,我个人就遇到不少问题,尤其是跟第三方的library比如Retrofit、ActiveAndroid结合使用的时候,会有不少问题,但瑕不掩瑜,我们依然可以用它完成很大部分的unit testing工作。

有任何意见或建议,或者发现文中任何问题,欢迎留言评论!

Leave a Reply