安卓测试驱动开发/安卓测试验证

安卓测试主要包括两种:单元测试;集成测试;测试主要通过mock依赖,验证行为。 Mock框架、单元测试框架、集成测试框架是TDD所需的主要工具。

Mock框架:Mockito

  • stubbed的方法没有必要verify
  • 当被测代码对返回值不关心时,不要stub
  • mock对象的方法默认将返回空值(null,空集合,默认基本类型值)
  • stub可以被重载,但当出现这种需求时,就说明stub已经太多了,需要改进设计
  • stub的顺序有影响,但不应依赖其顺序的影响
  • 默认使用Java原生equals进行判断,也支持ArgumentMatcher,有内置, 也支持自定义/Hamcrest,但最后者不建议使用(影响可读性)
  • 一旦使用了ArgumentMatcher,则所有的参数都要使用ArgumentMatcher
  • times(int)never()atLeastOnce()atLeast(int)atMost(int)验证调用次数,verify默认的是times(1),因此无需显式指定
  • 验证无返回值函数抛出异常:doThrow(new RuntimeException()).when(mockedList).clear();
  • InOrder可以验证调用的顺序(不同语句),原则上只需要验证关键逻辑,没必要 所有调用都需要验证、甚至其顺序
  • only()的语义:仅有该方法被调用,且仅被调用一次
  • never()的语义:该方法未被调用过
  • verifyZeroInteractions(...)的语义:mock对象没有任何方法调用
  • verifyNoMoreInteractions(...):验证没有其他的调用(除了此前验证的方法)
  • 对多次调用进行stub,最后一次将一直有效
  • doReturn()|doThrow()| doAnswer()|doNothing()|doCallRealMethod() family of methods
  • spy,对真实对象进行spy,部分mock。但是spy对象的操作和原有真实对象的操作是独立的
  • Capturing arguments for further assertions,在verify中可以捕获调用的参数,后续进行验证
  • reset mock,不建议使用
  • BDD,given, when, then
  • mock对象可以序列化
  • Verification with timeout
  • (new) Better generic support with deep stubs (Since 1.10.0)
  • How to mock dependencies in Unit, Integration and Functional tests; Dagger, Robolectric and Instrumentation
  • Testing made sweet with a Mockito

Assertion框架

单元测试:The Square Way

  • 单元测试是方法级别的测试,需要测试的是一个类的公开接口/方法,测试其逻辑正确性, 如果发现一个类的某个方法所使用的依赖难以mock,it's a smell,重构吧
  • 基础理论部分
    • The three steps of a unit test: arrange, act, and assert
    • check the return value of the method
    • get a reference to some publicly accessible property of the object being tested
    • check the state of the object’s injected dependencies
    • 所以编码时,应该尽量将代码逻辑的依赖通过注入的方式(或提供public setter, 或将被测函数的依赖作为参数传入)提供,以便于测试
    • post-act-state的验证要注意单元测试与集成测试的区别:单元测试只验证 一个方法的逻辑正确性,不验证多个方法(模块)一起工作的逻辑正确性;
    • static方法对测试非常不利,因为其对象依赖、方法依赖无法mock, 而其post-act-state也通常无法assert,开发过程中应尽量避免
  • 实践部分
    架构图
    androidstack-02.png
    Remove all business logic from app component classes (e.g., Activitys, Fragments, Services) and place that logic into "business objects", POJO objects whose dependencies are injected, android-specific implementations of android-agnostic interfaces.
    Delegate all application specific behavior to POJO objects whose dependencies are Android-specific implementations of Android-agnostic interfaces.
    • Non-UI App Components
      • 把业务逻辑(比如根据数据类型执行不同操作、检查数据合法性等)从组件类中 抽离出来,业务逻辑类对于组件类的依赖也不要直接使用,而是通过定义接口来 进行转发调用,这样就能使得业务逻辑类与SDK解耦。
      • 业务逻辑类的依赖通过依赖注入框架注入,便于测试时mock。
      • 而剩下的组件类工作简单,只负责转发业务逻辑类的功能请求,就没必要进行测试了。
    • UI App Component Classes
      • 通过MVP模式,将UI组件类和业务逻辑类解耦,同时移除对SDK组件类的依赖;
      • pre-act-state,post-act-state,测试对象的依赖中,如果mock框架 (如Mockito)可以mock,OK;如果不能mock(例如Activity,BroadcastReceiver) ,则可以通过定义接口的形式替换这些依赖,而接口的实现则是简单直接的转发,无需测试; pre-act-state便可以设置完毕,调用被测函数后,验证post-act-state即可。
    • Dependency Inject
      • 可以使用Constructor inject的类就不要使用Field inject。前者更利于单元测试。 其实除了SDK组件类,其他的类基本上都可以使用Constructor inject。
    • 无需依赖第三方框架(Robolectric,Dagger)
  • 单元测试的目标
    • 在非安卓系统组件相关的代码,直接每个方法进行测试,很好理解
    • 系统组件相关的代码,主要测:试依赖于生命周期函数的逻辑;由简单UI交互引发的逻辑; 自定义接口的逻辑(如MVP中的View);
  • 与其他框架/工具的整合

    • RxJava

      • Rx为异步而生,但测试往往需要同步进行验证
      • 可通过myObservable.toBlocking().first();进行同步
      • 也可通过官方的TestSubscriber,该类提供了众多实用的方法,例如同步获取 Observable发射的所有对象,断言没有onError,等待onComplete等
      • 处理生产代码中的异步问题,可以在测试时hook Schedulers.io()Schedulers.immediate(),但在hook之前需要reset RxJavaPlugins, 在RxJava中这个方法是package private,所以做到这点有点hack,在RxAndroid中则 无需如此麻烦,因为或者RxAndroid提供了很好的hook支持。

         package rx.plugins;
        
         public class RxJavaTestPlugins extends RxJavaPlugins {
             RxJavaTestPlugins() {
                 super();
             }
        
             public static void resetPlugins(){
                 getInstance().reset();
             }
         }
        
         ...
         RxJavaTestPlugins.resetPlugins();
         RxJavaPlugins.getInstance().registerSchedulersHook(new RxJavaSchedulersHook() {
             @Override
             public Scheduler getIOScheduler() {
                 return Schedulers.immediate();
             }
         });
        

        另外有一点需要指出的是,要想RxJava的hook起作用,必须要在Schedulers 类初始化之前进行hook,那么在测试的时候,只能通过实现自定义的TestRunner来做到了 ,在TestRunner的构造函数中进行reset和hook就OK了。而RxAndroid的hook则没这 么麻烦,在测例的setUp函数中进行就OK。

      • RxJava还能设置ObservableExecutionHook,示例: RxJavaPlugins.getInstance().registerObservableExecutionHook(new DebugHook(new DebugNotificationListener() {...}
    • 网络库:Retrofit,OkHttp

集成测试

  • 集成测试的级别是什么?wiki定义为:把各个经过单元测试的模块组合起来,作为一个 整体进行测试,是验证测试的前一步。
  • 那么需要组合多少个unit呢?这个应该视具体情况和实际操作来决定,目前来看,对于 安卓开发来说,以Activity作为集成测试的单位比较合适,但是也不尽然,例如需要测试不 同Activity之间的状态同步时,Activity1进入Activity2,并在其中进行了操作, 改变了应用的状态,回到Activity1也希望能够响应该变化,那么测试范围就涉及多个Activity了。
  • 测试框架

  • 和一些其他框架的整合
    • Dagger2
      • 生产代码的依赖都是通过依赖注入框架注入,本应是有利于测试的,但是如何通过依 赖注入框架把mock的依赖注入进去呢?
      • 总的来说,都是通过使得main和test使用不同的module,test的module provide mock的依赖,main的module provide真实的依赖
      • 思路1:利用flavor/build variant,专门创建一个用于注入测试依赖的variant, 其中维护测试依赖的component;不用打破生产代码的封装特性;但是增加了维护成本, 有两套component需要维护,而且这两套component必须切换AS的build variant才能切换,不能同时维护;
      • 思路2:修改生产代码的component创建/获取途径,使得测试时可以设置测试用的 component(能够注入测试依赖);后期不用切换AS的build variant就能进行重构; 一定程度上打破了封装性;
      • 思路3:集成测试代码使用测试专用的Application类(生产代码app的子类), 自定义test runner,使得测试运行时使用测试app类,在其中初始化dagger component,完美。
      • http://blog.sqisland.com/2015/12/mock-application-in-espresso.html
      • http://blog.egorand.me/reliable-functional-tests-with-espresso-and-dagger/
      • DaggerMock,将mockito和dagger结合起来
    • StorIO

回归测试

  • 验证功能无回退
  • 对于视觉检查来说,screenshot-tests-for-android似乎不错
    • 首先需要确认,当前版本是正确的(通过了单元测试与集成测试)
    • 在此基础上,对渲染数据的静态场景,生成截屏
    • 以后在相同场景下(测例),再次截屏,并进行对比

results matching ""

    No results matching ""