android mvp 单元测试实践

起因

最近摊上个大事儿。某次迭代发布中,某一个注册流程因为密码/验证码参数传反,又恰好因为种种原因黑盒测试没有覆盖到,最终只能通过重新发包解决。反思这个问题的原因,其一,这种参数类型一致的函数调用,编译器没办法判断对错,又难免由于手抖、神智不清、敲码过快等莫名其妙的原因输入错误;其二,不能过分依赖黑盒覆盖,特别是在测试资源有限的前提下。根据很久以前的一些经验,觉得重拾一下单元测试这个技能,应该可以作为一种测试的补充,来规避这些低级错误。于是,就针对现有代码,做了一次单元测试实践。

环境与平台

  • android studio 2.1.2

  • JRE 1.8.0

  • 单元测试工具 AndroidJUnitRunner

  • gradle 版本 2.10

  • 被测试代码架构 MVP

建立用例与重构

当初团队内部刚刚推行MVP的时候,就了解到这个架构对单元测试比较友好,这次可以体验一下究竟有多友好了。闲话少叙,书接上文,首先要明确一下我们的初始目标:避免某些函数调用中,同类型参数传反的笔误。那么从大的方向上来思考,针对MVP这种结构,我们应当伪造一个View,然后以测试Presenter为主,并且需要在Presenter与Model的数据传递中来判别参数是否传的正确;然而具体到具体的问题来具体分析的时候,就发现情况没那么简单。不是以测试驱动开发的代码,在添加单元测试用例的时候很难不去修改源码——小范围的重构是难免的,或许还要破坏一些原有类的封装。在写用例之前,你需要模拟好测试运行前的环境、解掉该解掉的依赖、定义需要注入断言程序运行的接口等等事项。

真实的代码环境

网上似乎所有的单元测试相关的博客都喜欢拿计算器来说事儿,MVP的则喜欢用登陆注册做示例,然而真实的登陆注册往往要复杂得多。手机、邮箱、社交账号几种方式,再根据界面设计上的相似性抽象复用,最终的要考虑的实际问题有很多。现在单以注册流程为例,被测试的 presenter 类,针对的是注册的最后一步界面。假设现在要实现一个邮箱账户注册的单元测试用例,那么针对邮箱账号的注册接口的调用,就是界面上确认按钮的点击响应,在被测试的 presenter中 实现是这个样子的:

public void confirm() {
    switch (mView.getMode()) {
        case AccountConfirmActivity.MODE_CHANGE_PASSWORD:
            resetPassword();               
            break;

        case AccountConfirmActivity.MODE_FORGET_PASSWORD:
            resetPassword();               
            break;

        case AccountConfirmActivity.MODE_REGISTER:
            register();   
            break;
    }
}

private void register() {
    switch (mView.getPlatform()) {
        case AccountConfirmActivity.PLATFORM_EMAIL:
            TaoXiaoQiUser.getInstance().registerAccountWithEmail(mCountryCode, mEmail, mView.getPassword(), mIRegisterCallback);
            break;

        case AccountConfirmActivity.PLATFORM_PHONE:
            TaoXiaoQiUser.getInstance().registerAccountWithPhone(mCountryCode,mPhoneNum,mView.getPassword(),mView.getValidateCode(),mIRegisterCallback);
            break;
    }
}

首先,界面的复用导致代码上对确定按钮的响应有不同的处理,具体是那种情况取决于View层的回调;其次,由于网络请求接口直接使用SDK封装过的,所以代码中并没有model这一层,而是直接调用SDK、传回调接口的方式实现。整个流程还没完,对于SDK的注册调用,传入的回调接口定义如下:

private IRegisterCallback mIRegisterCallback = new IRegisterCallback() {
    @Override
    public void onSuccess(User user) {
        mHandler.sendEmptyMessage(MSG_REGISTER_SUCC);
    }

    @Override
    public void onError(String errorCode, String errorMsg) {
        Message msg = MessageUtil.getCallFailMessage(MSG_REGISTER_FAIL, errorCode, errorMsg);
        mHandler.sendMessage(msg);
    }
};

可以看出,回调经过了简单的包装之后交给了handler:

@Override
public boolean handleMessage(Message msg) {
    switch (msg.what) {
        case MSG_REGISTER_FAIL:
            mView.modelResult(msg.what, (Result) msg.obj);
            break;

        case MSG_REGISTER_SUCC:
            loginSuccess();
            break;
    }
    return super.handleMessage(msg);
}

成功的分支走登陆成功的逻辑,这里面耦合了登陆成功之后的统计、配置处理;失败的分支回调给了View层,一般是做显示出错提示处理。

差点漏掉了,要测试这个类的前提是要有这个类的对象实体,显然我们需要知道它的构造是什么:

public AccountConfirmPresenter(Activity activity, IAccountConfirmView validateCodeView){
        super(activity);
        mView = validateCodeView;
        mContext = activity;
        initData(activity);
    }

下手前的问题

要知道写一个单元测试用例跟把大象装进冰箱差不多——都要分三步,先模拟好运行环境;再输入用例数据;最后断言函数运行导致的变化。说起来简单,但看到上边整个注册流程,总有些无从下手,把能想到的问题都罗列下来。

  1. 要测试函数confirm,无参,却要运行注册-邮箱这个流程上,如何控制;
  2. 回到最初的问题,注册接口的参数传反的预判,可是最终调用到的私有函数register中直接调用了SDK的接口,如何断言参数的传递是正确的;
  3. 在哪里断言所有流程跑通的结果;
  4. loginSuccess涉及到应用配置、统计结果,这部分是不应当放入在单元测试中的,如何处理;
  5. 用例数据应当如何设计;
  6. 构造函数中,initData 根据Activity的Intent获取了几个初始数据,手机号/邮箱/默认国家码等,这些数据怎么处理。

破题

有问题自然有答案,没有答案的话我们可以修改问题,再弄出个答案。换句话说,实在搞不定,只能修改源码,让源码具有更强的可测试性。好在以上几个问题还不至于需要大规模的修改功能代码。

第一个与第六个问题其实就是模拟运行环境的问题,从confirm到register,可以看到分支的选区依赖于View的接口getMode、getPlatform,回到构造函数,本身我们也是要伪造一个View层传递进去的。所以我们需要伪造一个可以传递我们用例数据的View传递给被测试类,至于构造函数中的initData,这个方法我们不需要它执行,因为我们需要自己的测试数据来设定手机号/邮箱/默认国家码,这种情况下,就需要修改 initData 函数的权限为 protected ,新建一个 ForkAccountConfirmPresenter 类覆盖掉这个方法的运行。那么,现在我们的测试对象变成了 ForkAccountConfirmPresenter;

第二个问题是核心要解决的问题,乍一看也是一大难点。好在SDK函数TaoXiaoQiUser.getInstance()返回的是一个接口 ITaoXiaoQiUser,让问题找到了答案。可以把这个接口的获取抽象成一个protected函数,同样利用继承覆盖的方式,注入我们自己的mock User;

第三、四个问题需要一起来说明。loginSuccess本身是一个不需要执行的、需要解掉的依赖,跑个测试用例影响到数据统计和应用配置是不允许的,那么这里的处理跟 initData 函数一样就好。至于断言的位置,在本用例中传递参数是否正确是需要断言的,也就是说我们 mock 的 User 中需要有断言能力;再一点就是整个流程的走通,注册逻辑无非是成功与否两种情况,根据代码可以知道,注册失败的逻辑最后会返回到View层的 modelResult 函数、成功的逻辑会调用loginSuccess函数。也就是说,伪造的View的modelResult、继承覆盖的loginSuccess需要有直接或者间接的断言能力;

上面几个问题讲的是用例实现需要源码改动、新建辅助测试类等需要行的方便,第五个问题则是用例数据设计的本身。用例要覆盖到代码的所有分支,一般就要看输入数据是否覆盖到了所有的情况,通常是普通数据、边界数据和无效数据三种情况,再考虑到测试与断言使用的便捷性。先定义一个数据类包含输入参数、输出断言的数据等,再定义一个专用的数据类,描述所有可能的情况即可。在测试用例中,调用不同的数据断言对应的不同输出。

实现

这里贴部分代码,足以解释上面破题的思路就好。

被测试类

public class AccountConfirmPresenter extends BasePresenter{
        private void register() {
            switch (mView.getPlatform()) {
                case AccountConfirmActivity.PLATFORM_EMAIL:
                    getTaoXiaoQiUser().registerAccountWithEmail(mCountryCode, mEmail, mView.getPassword(), mIRegisterCallback);
                    break;

                case AccountConfirmActivity.PLATFORM_PHONE:
                    getTaoXiaoQiUser().registerAccountWithPhone(mCountryCode,mPhoneNum,mView.getPassword(),mView.getValidateCode(),mIRegisterCallback);
                    break;
            }
        }

        protected ITaoXiaoQiUser getTaoXiaoQiUser(){
            return TaoXiaoQiUser.getInstance();
        }

        protected void initData(){
            //...
        }

        protected void loginSuccess() {
            //...
        }

        //for test
        public void setCountryCode(String mCountryCode) {
            this.mCountryCode = mCountryCode;
        }
        //for test
        public void setPhoneNum(String mPhoneNum) {
            this.mPhoneNum = mPhoneNum;
        }
        //for test
        public void setEmail(String mEmail) {
            this.mEmail = mEmail;
        }
    }

原本的被测试类 AccountConfirmPresenter ,开放了三个私有变量的set函数供测试用例配置测试数据;两个函数权限由private降级到protected,方便Fork类覆盖;SDK调用接口被抽象为protected级函数调用,同样为了传入山寨货User。

山寨被测试类

public class ForkAccountConfirmPresenter extends AccountConfirmPresenter {

    private MockTaoXiaoQiUser mMockUser;
    private boolean mIsCallLoginSuccess = false;


    public ForkAccountConfirmPresenter(Activity activity, IAccountConfirmView validateCodeView,MockTaoXiaoQiUser user) {
        super(activity, validateCodeView);
        mMockUser = user;
    }

    @Override
    protected ITaoXiaoQiUser getTaoXiaoQiUser() {
        return mMockUser;
    }

    @Override
    protected void initData(Activity activity) {
        //do nothing
    }

    @Override
    protected void loginSuccess() {
        mIsCallLoginSuccess = true;
    }

    public boolean isIsCallLoginSuccess(){
        return mIsCallLoginSuccess;
    }
}

山寨类通过继承覆盖掉了众多不该调用的函数、接入了伪造的User、提供了loginSuccess被调用的断言标志。

伪造User

public class MockTaoXiaoQiUser implements ITaoXiaoQiUser {
    @Override
    public void registerAccountWithEmail(final String countryCode, final String email, final String passwd, final IRegisterCallback callback) {
        if(email.equals(UnitCaseData.MOCK_REGIST_EMAIL_INPUT_SUCCESS.userName)){
            Assert.assertSame(passwd, UnitCaseData.MOCK_REGIST_EMAIL_INPUT_SUCCESS.passWord);
            callback.onSuccess(null);
        }else if(email.equals(UnitCaseData.MOCK_REGIST_EMAIL_INPUT_FAIL.userName)){
            Assert.assertSame(passwd, UnitCaseData.MOCK_REGIST_EMAIL_INPUT_FAIL.passWord);
            callback.onError(UnitCaseData.MOCK_REGIST_EMAIL_INPUT_FAIL.errorCode, UnitCaseData.MOCK_REGIST_EMAIL_INPUT_FAIL.errorMsg);
        }else{
            Assert.fail();
        }
    }
}

伪造的User类断言了参数是否正确、要覆盖到所有测试数据的调用返回,实际上是个模拟服务端返回的家伙。

伪造的View

public class MockAccountConfirmView implements IAccountConfirmView {
    private int mMockMode = 0;
    private int mMockPlatform = 0;
    private String mMockCode;
    private String mMockPassword;
    private IAccountAssert mIAccountAssert;

    public interface IAccountAssert{
        void check(int what, Result result);
    }

    public MockAccountConfirmView(){

    }

    public void setmMockMode(int mMockMode) {
        this.mMockMode = mMockMode;
    }

    public void setmMockPlatform(int mMockPlatform) {
        this.mMockPlatform = mMockPlatform;
    }

    public void setmMockCode(String mMockCode) {
        this.mMockCode = mMockCode;
    }

    public void setmMockPassword(String mMockPassword) {
        this.mMockPassword = mMockPassword;
    }

    public void setmIAccountAssert(IAccountAssert mIAccountAssert) {
        this.mIAccountAssert = mIAccountAssert;
    }

    @Override
    public String getValidateCode() {
        return mMockCode;
    }

    @Override
    public String getPassword() {
        return mMockPassword;
    }

    @Override
    public void modelResult(int what, Result result) {
        if(mIAccountAssert != null){
            mIAccountAssert.check(what,result);
        }
    }

    @Override
    public int getMode() {
        return mMockMode;
    }

    @Override
    public int getPlatform() {
        return mMockPlatform;
    }
}

伪造的View是对Activity的替代。它伪造了环境标志MODE&PLATFORM、伪造了密码/验证码供测试用例设置、建立了IAccountAssert断言接口供测试用例断言modelResult函数的回调情况。

测试用例

@Test
public void emailRegister() throws Exception {
    //配置环境
    mMockAccountConfirmView.setmMockCode(AccountConfirmActivity.EXTRA_ACCOUNT_CONFIRM_MODE);
    mMockAccountConfirmView.setmMockPlatform(AccountConfirmActivity.PLATFORM_EMAIL);

    mMockAccountConfirmView.setmMockPassword(UnitCaseData.MOCK_REGIST_EMAIL_INPUT_SUCCESS.passWord);
    mPresenter.setEmail(UnitCaseData.MOCK_REGIST_EMAIL_INPUT_SUCCESS.userName);
    mMockAccountConfirmView.setmIAccountAssert(new MockAccountConfirmView.IAccountAssert() {
        @Override
        public void check(int what, Result result) {
            Assert.assertEquals(what, AccountConfirmPresenter.MSG_REGISTER_SUCC);
        }
    });

    //调用被测试接口
    mPresenter.confirm();

    //结果断言
    Assert.assertTrue(mPresenter.isIsCallLoginSuccess());
}

严格来讲这只是小半个测试用例,因为它只包含了注册成功的部分流程。

一步一个脚印(kēng)

实现上当然不是一气呵成的。android studio上第二次使用AndroidJUnitRunner依然是坑点多多,上一次是半年以前、也只是基本过了一下,记忆并非犹新、跟没有一样。加之android studio本身升级、工程各路依赖冲突,真是举步维艰。

  • 配置
    关于单元测试的配置都是在gradle配置中完成,首先AndroidJUnitRunner的配置:

    defaultConfig {
        //...
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
    

    其次,依赖:

    dependencies {
        //...
        testCompile 'junit:junit:4.12'
        //ADD THESE LINES:
        androidTestCompile 'com.android.support.test:runner:0.2'
        androidTestCompile 'com.android.support.test:rules:0.2'
        androidTestCompile 'com.android.support.test.espresso:espresso-core:2.1'
    }
    

    这应该不是最新版本的依赖,也可能并非都是必须的,完全取决于用例的需求。不依赖于android特殊实例(Activity、Context等)的用例属于纯功能型的,只需要testCompile的依赖,它的代码位置在src目录下的test目录中;需要android界面支持的依赖是androidTestCompile,用例代码在src的androidTest目录下。测试用例的代码最好使用android studio自带的工具方法生成,它可以保证你的用例代码在正确的位置。

  • 异常: ‘testClasses’ not found

    正常的工程目录一般都有不少的module依赖,而不是像各种实例demo中只有一个干巴巴的app module。这个时候或许会遇到这个异常:

    Error:FAILURE: Build failed with an exception.

    * What went wrong:

    Task 'testClasses' not found in project ':TaoXiaoQiSdk'.
    

    * Try:

    Run gradle tasks to get a list of available tasks. Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output
    

    这个时候,需要在提示的model的gradle配置文件中添加以下配置,表示不要瞎管闲事,这里没有需要测试的类:

    task testClasses {
        doLast {
            println 'This is a dummy testClasses task'
        }
    }
    
  • 错误: 程序包android.support.test.rule不存在

    这个时候需要检查你的gradle配置,各种依赖是否配置到位,最重要的是AndroidJUnitRunner在defaultConfig中是否漏配。早期的android studio版本需要在Build Variants中选择对应的测试用例方式,2.1之后已经默认使能了,如果想回复之前的样子需要在setting中取消勾选:

    按目录找不是很靠谱,因为android studio在不断升级中各种功能似乎会换位置,直接搜关键字这招简单粗暴又实用。

  • 测试用例的位置

    如果不依赖android的实例,仅仅使用JUnit Test的话,自然是百无禁忌,哪个module的测试类,就放到哪个目录下就好;但如果需要android页面支持,则最好统一放到application module的代码目录下。我遇到的问题是在子module下运行子module的测试用例时,会报dex方法数超出65535的错误,关于多dex处理只有在application module的配置中处理时,最好把用例都放在此目录下,避免这种问题。

  • 依赖异常

    遇到了几种冲突,其一:

    Error:Conflict with dependency ‘com.google.code.findbugs:jsr305’. Resolved versions for app (3.0.0) and test app (2.0.1) differ. See http://g.co/androidstudio/app-test-app-conflict for details.

    在gradle文件中增加如下配置:

    android{
        //...
        configurations.all {
            resolutionStrategy.force 'com.google.code.findbugs:jsr305:3.0.0'
        }
    }
    

    其二:

    Error:Conflict with dependency ‘com.android.support:support-annotations’. Resolved versions for app (23.1.1) and test app (22.0.0) differ. See http://g.co/androidstudio/app-test-app-conflict for details.

    在依赖配置中增加annotations的设置:

    androidTestCompile 'com.android.support:support-annotations:23.1.1'
    

    以上解决方案来源于 stackoverflow

奔跑吧,用例

把源码注册部分参数改反,之后运行用例,可以得到:

java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.fail(Assert.java:100)
at login.mock.MockTaoXiaoQiUser.registerAccountWithEmail(MockTaoXiaoQiUser.java:58)
at com.TaoXiaoQi.stencil.presenter.login.AccountConfirmPresenter.register(AccountConfirmPresenter.java:214)
at com.TaoXiaoQi.stencil.presenter.login.AccountConfirmPresenter.confirm(AccountConfirmPresenter.java:193)
at login.AccountConfirmPresenterTest.emailRegister(AccountConfirmPresenterTest.java:70)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at ...

Tests ran to completion.

成功预防了参数传反的低级错误。

代码修改正确之后的运行结果:

我最喜欢的绿色进度条

总结

  • 在类似MVP架构的代码中做单元测试确实十分便捷,无法想象如果是之前把控制逻辑糅合在Activity代码中的做法如何进行测试。并且在理论上,只对presenter/module进行测试的话无需依赖android环境,测试效率会大大提高。当然,为图省事儿在本例中还是使用了android环境,后续可以考虑采用mock库来模拟Activity的行为,来摆脱对Instrumentation的依赖。
  • 用例的添加,会对源码进行一定程度的“破坏”。测试需要,暂时无法避免,目前想到降低损失的方法,可以增加必要的文字注释;类似android源码的“@Test”注释,也是一个可以考虑的方向;一些属性开set接口的行为,可以使用反射代替。此外,新代码编写的过程中,要考虑到代码的可测试性也是必要的。

  • 时间损耗。以上编写一个接口函数之中一种流程的一种情况的测试用例,大概消耗了我4个工时的时间。当然这里包含了源码重构、用例设计、数据结构构思、开发工具单元测试部分熟悉、异常解决等等各方面的时间,实际上第一个用例跑通之后,同一个被测试类的其他用例和测试数据的建立速度是很快的。但用例的规模和有效性,是由业务的复杂程度决定的,并且用例也是需要维护的,这部分成本是需要衡量的。

  • 接口是个好东西,山寨伪造、接缝注入,单元测试必备良药。

参考

在Android Studio中进行单元测试和UI测试

Android单元测试初探

官方文档 Building Local Unit Tests

感谢您赏个荷包蛋~