Android Junit单元测试、异步测试简介及框架指南

发表于:2018-1-22 11:20

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:Zcclucky    来源:51Testing软件测试网采编

  本文解决的问题
  1. 如何使用junit 做Android 单元测试
  2. 如何使用junit 做Android 异步接口单元测试
  3. 使用作者封装的框架,优雅地用junit 做Android 异步接口单元测试 [doge]
  Junit 作为Android Studio 原生支持的测试框架可以很方便的执行单元测试,并且通过注解 @Test 可以直接标记方法为测试case 然后在子线程中执行。 标记为@UiThreadTest 时,测试case 将在 ui线程中执行。
  但是由于junit 本身的设计,当每个test方法执行结束时,该方法的运行线程会一并kill掉, 因此对于异步调用的方法,子线程会一并回收,回调函数也无法执行。
  举个栗子,以下的测试case 将无法收到回调并会报错
  @Runwith(Junit4.calss)
  class Test1{
      public static final String TAG="sample test";
      @Test
      public void test1(){
          new YourAsyncJob().run(new YourAsyncTestCallback(){
              @Override
              public void onFinished(){
                  Log.i(TAG, "async call back");
              }
          });
          Log.i(TAG, "run async ok");
      }
  }
  解决方法 阻塞 test case
  既然测试线程死掉之后对应子任务都会失败,最直接的方案就是直接阻塞对应
  <span id="section1">1 线程锁</span>
  庆幸Java 提供了极其好用的原生api。CountDownLatch 能够直接阻塞线程,等待完成。 当调用 await()方法时,对应线程会阻塞至 countdownlatch 的 count 变为0 时,恢复运行。因此我们得到以下方案
  @Runwith(Junit4.calss)
  class Test1{
      public static final String TAG="sample test";
      @Test
      public void test1(){
          final CountDownLatch mutex = new CountDownLatch(1);
          new YourAsyncJob().run(new YourAsyncTestCallback(){
              @Override
              public void onFinished(){
                  Log.i(TAG, "async call back");
                  mutex.countDown();
              }
          });
          Log.i(TAG, "run async ok");
          mutex.await();
      }
  }
  跑了一下,似乎可行,log 出来了。
  然而在实际使用中又遇见了新的问题。
  2 Looper 阻塞(Handler thread)
  做过sdk的同学可能会遇见这样的需求:
  业务端的同学主线程(或handler线程)发起异步请求,执行完后(通过handler)回调至主线程(或handler线程)。
  在处理这个问题是,我们也发现 [方案一]中的回调函数事实上也只能在异步线程中执行,而不能切换回发起线程(测试线程)中执行。这显然不能满足我们优雅的异步接口的测试需求。于是我们需要新的方案2 Looper 阻塞 通过looper 阻塞 并且实现回调函数的线程切换。
  上述问题的根本就是handler 线程的回调及切换问题,这个时候由于测试线程是没有looper 的,我们需要为它营造一个这样的环境。 同时,既然有looper 的存在, 那么它的自旋功能也就可以满足我们对阻塞的需求,这样的情况下,我们似乎可以直接抛弃掉之前的CountDownLatch了。
  于是我们得到了以下代码
  @Runwith(Junit4.calss)
  class Test1{
      public static final String TAG="sample test";
      @Test
      public void test1(){
         Looper.prepare();
          //final CountDownLatch mutex = new CountDownLatch(1);
          new YourAsyncJob().run(new YourAsyncTestCallback(){
              @Override
              public void onFinished(){
                  Log.i(TAG, "async call back");
                  //mutex.countDown();
                  Looper.myLooper().quitSafely();
              }
          });
          Log.i(TAG, "run async ok");
          // mutex.await();
          Looper.loop();
      }
  }
  看起来是可以适应这样的过程,于是开始愉快的测试起来,但是很快,又遇见了新的问题。
  3 Handler thread + 封装
  自动化测试好处在于,自动的批量地执行测试case。于是在接下来的过程中我们用到了
      @RunWith(Parameterized.class)
  和@Parameterized.Parameters 注解来执行参数化的批量输入。
  于是新的问题出现了,由于实际运行时@Test方法运行在同一个子线程,因此多次Looper.prepare() 显然是不实际的,(会有RuntimeException)。
  于是最直接解决的办法是,一开始prepare好么?
  事实上也不行,这样的情况回存在如下问题。
  何时执行Looper.myLooper().quitSafely()
  熟悉Looper 的朋友知道,一旦quit之后,Looper 的queue 将无法使用。 而为了使阻塞的@Test线程恢复运行至结束,又必须在[方案2]的基础上解除loop().
  于是为了满足这样的情况,我们只能通过另起一个HandlerThread 执行这种需要跨线程回调的接口测试。然后在回调执行完毕前,阻塞最初的测试线程@Test线程,保证HandlerThread 的存活。(这里我们每次setup 都会新起一个线程,原因是,无法跨TestCase 重用这个线程,当Case执行完后,该线程会被系统强制回收)
  于是获得了如下的内容
  @RunWith(Parameterized.class)
  class Test1{
      public static final String TAG="sample test";
      private HandlerThread t;
      private Handler tH;
      @Parameterized.Parameters
      public static Collection<Object[]> data() {
          //测试数据
          return Arrays.asList(new Object[][]{
                  {"TES-1085-7", "TES-1085-7"},
                  {null, null},
          });
      }
      @Before
      public void setUp() throws Exception {
            t = new HandlerThread("test");
            t.start();
            tH = new Handler(t.getLooper());
      }
      @Test
      public void test1(){
          final CountDownLatch mutex = new CountDownLatch(1);
          tH.post(new Runnable(){
              @Override
              public void run(){
                  new YourAsyncJob().run(new YourAsyncTestCallback(){
                      @Override
                      public void onFinished(){
                          Log.i(TAG, "async call back");
                          mutex.countDown();
                      }
              }
          });
          Log.i(TAG, "run async ok");
          });
         mutex.await();
      }
  }
  4 优化及处理异常
  [方案3]基本能够处理一般的批量测试。但是作为一个严谨的程序员,这样的代码显然是不够优雅的。于是我们需要二次封装,封装后的代码调用会简洁很多,如下
  @RunWith(Parameterized.class)
  class Test1 extend ZCCBase{
      public static final String TAG="sample test";
      @Parameterized.Parameters
      public static Collection<Object[]> data() {
          //测试数据
          return Arrays.asList(new Object[][]{
                  {"TES-1085-7", "TES-1085-7"},
                  {null, null},
          });
      }
      @Before
      public void setUp() throws Exception {
           super.setUp();
      }
      @Test
      public void test1(){
          runAsyncTest(new AsyncTest(){
              @Override
              public void onRun(){
                  new YourAsyncJob().run(new YourAsyncTestCallback(){
                      @Override
                      public void onFinished(){
                          onAsyncTestFinished();
                      }
              }
          });
      }
  }
  是不是优雅了很多,具体框架和demo使用可以参考 我的github
  还没完,我们还剩下一个问题。实际操作时,异步线程中的Assert Error 如果直接抛出的话,并不能在Android Studio 的Run Text 窗口中直接显示出来,而是会显示成 进程crash 的日志,真实原因需要去logcat 中查找。这显然不是健全的,因此我们还需要把对应的Throwable 抛回测试线程。 这一功能也已经封装在 我的github中。


上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号