关于写异步代码测试用例的一些思考

如果说异步代码不好写是共识的话，那么写异步代码测试用例就更难了。最近我刚刚完成了一个 Flaky 测试，所以想和大家分享一些关于写异步测试用例的想法。

这篇文章里，我们会探索一个关于异步测试用例的常见问题 —— 如何强制规定某些线程的顺序，如何强制某一个线程操作早于另一些执行。通常我们并不想强行规定线程之间的顺序，因为这违背了多线程的原则，所谓多线程就是 为了做到并发，从而使得 CPU 可以根据当前资源及应用状态选择最佳的执行顺序。但是在测试中，为了确保测试结果的稳定性，又必须明确线程顺序。

测试节流阀（Throttler）

在软件业里节流阀指的是用于限制并发操作个数，预留资源的模式，好比连接池，网络缓存，或者 CPU 密集型操作。和其他同步工具不同的是，节流阀的角色是启动“快速失败”机制，即促使超额请求立即失败，而不是等待。“快速失败”机制之所以重要，是因为切 换操作，等待操作会消耗资源 —— 端口，线程，内存等。

以下就是一个节流阀的简单实现（基本上是信号量的包装，实际应用中应该是等待，重试等等）

 
 
    
  
  
  1. class ThrottledException extends RuntimeException("Throttled!")
    2. 
  
  
  2. class Throttler(count: Int) {
    3. 
  
  
  3.   private val semaphore = new Semaphore(count)
    4. 
  
  
  4.   def apply(f: => Unit): Unit = {
    5. 
  
  
  5.     if (!semaphore.tryAcquire()) throw new ThrottledException
    6. 
  
  
  6.     try {
    7. 
  
  
  7.       f
    8. 
  
  
  8.     } finally {
    9. 
  
  
  9.       semaphore.release()
    10. 
  
  
  10.     }
    11. 
  
  
  11.   }
    12. 
  
  
  12. }
    13.

现在我们开始基本的单元测试：测试单线程的节流阀（我们使用测试框架 specs2)。本例里，我们会验证顺序调用是否会超过节流阀的最大限制（maxCount变量如下所示）。注意，这里我们用的是单线程，所以我们并不验证节流阀的“快速失败”功能，这里的节流阀都处于不饱和状态。事实上，我们只会测试节流阀在不饱和状态下不会终止操作。

 
 
    
  
  
  1. class ThrottlerTest extends Specification {
    2. 
  
  
  2.   "Throttler" should {
    3. 
  
  
  3.     "execute sequential" in new ctx {
    4. 
  
  
  4.       var invocationCount = 0
    5. 
  
  
  5.       for (i <- 0 to maxCount) {
    6. 
  
  
  6.         throttler {
    7. 
  
  
  7.           invocationCount += 1
    8. 
  
  
  8.         }
    9. 
  
  
  9.       }
    10. 
  
  
  10.       invocationCount must be_==(maxCount + 1)
    11. 
  
  
  11.     }
    12. 
  
  
  12.   }
    13. 
  
  
  13.   trait ctx {
    14. 
  
  
  14.     val maxCount = 3
    15. 
  
  
  15.     val throttler = new Throttler(maxCount)
    16. 
  
  
  16.   }
    17. 
  
  
  17. }
    18.

测试并发节流阀

前一个例子里，节流阀处于不饱和状态，因为单线程里节流阀一般都不会饱和。下面我们来测试一下多线程环境下节流阀是否还能工作良好。

设置如下：

 
 
    
  
  
  1. val e = Executors.newCachedThreadPool()
    2. 
  
  
  2. implicit val ec: ExecutionContext=ExecutionContext.fromExecutor(e)
    3. 
  
  
  3. private val waitForeverLatch = new CountDownLatch(1)
    4. 
  
  
  4. 
  
  
  5. override def after: Any = {
    6. 
  
  
  6.   waitForeverLatch.countDown()
    7. 
  
  
  7.   e.shutdownNow()
    8. 
  
  
  8. }
    9. 
  
  
  9. 
  
  
  10. def waitForever(): Unit = try {
    11. 
  
  
  11.   waitForeverLatch.await()
    12. 
  
  
  12. } catch {
    13. 
  
  
  13.   case _: InterruptedException =>
    14. 
  
  
  14.   case ex: Throwable => throw ex
    15. 
  
  
  15. }
    16.

ExecutionContext 用来构建 Future，waitForever 方法用来持有线程，直到测试结束前的锁释放。接下来的函数里，我们会关闭一个执行服务。

以下就是一个测试节流器多线程行为的例子：

 
 
    
  
  
  1. "throw exception once reached the limit [naive,flaky]" in new ctx {
    2. 
  
  
  2.   for (i <- 1 to maxCount) {
    3. 
  
  
  3.     Future {
    4. 
  
  
  4.       throttler(waitForever())
    5. 
  
  
  5.     }
    6. 
  
  
  6.   }
    7. 
  
  
  7.   throttler {} must throwA[ThrottledException]
    8.

我们创建了 maxCount 个线程（调用 Future{}）来调用 waitForever 函数，该函数会一直直到道测试结束。然后我们绕开节流阀执行另一个操作 —— maxCount + 1。预期的行为是，此时应该抛出 ThrottledException 例外。但是，也许预期的例外并不发生，因为接力器的最后的一个调用可能会比 future 里的先执行（future 里会抛出例外，但是这不是预期结果）。

上面这个测试的问题是，在像期望中那样节流阀抛出异常然后导致节流阀被违反之前，我们无法确定所有的线程都已经开始并且在 waitForever 函数中被阻塞。为了修复这个问题，我们需要一些方法去等待所有 future 开始。这有一个我们大多数都很熟悉的一种方法：只要增加一个 sleep 函数等待一些合适的时间。

 
 
    
  
  
  1. "throw exception once reached the limit [naive, bad]" in new ctx {
    2. 
  
  
  2.   for (i <- 1 to maxCount) {
    3. 
  
  
  3.     Future {
    4. 
  
  
  4.       throttler(waitForever())
    5. 
  
  
  5.     }
    6. 
  
  
  6.   }
    7. 
  
  
  7.   Thread.sleep(1000)
    8. 
  
  
  8.   throttler {} must throwA[ThrottledException]
    9. 
  
  
  9. }
    10.

好了，现在这个测试几乎都能通过了，但是这个方法还是错的因为下面这两个原因：

测试持续的时间至少会和我们设置好的”合适的时间”差不多久。

在非常罕见的情况下，比如机器处于高负载的时候，这个合适的时间不一定足够。

如果你仍然感到疑惑，可以搜索一下 Google 更多的原因。

一个更好的方式是将我们的线程(future)的开始和我们期望的东西同步起来。我们来使用 java.util.concurrent 里面的 CountDownLatch 类：

 
 
    
  
  
  1. "throw exception once reached the limit [working]" in new ctx {
    2. 
  
  
  2.   val barrier = new CountDownLatch(maxCount)
    3. 
  
  
  3. 
  
  
  4.   for (i <- 1 to maxCount) {
    5. 
  
  
  5.     Future {
    6. 
  
  
  6.       throttler {
    7. 
  
  
  7.         barrier.countDown()
    8. 
  
  
  8.         waitForever()
    9. 
  
  
  9.       }
    10. 
  
  
  10.     }
    11. 
  
  
  11.   }
    12. 
  
  
  12. 
  
  
  13.   barrier.await(5, TimeUnit.SECONDS) must beTrue
    14. 
  
  
  14. 
  
  
  15.   throttler {} must throwA[ThrottledException]
    16. 
  
  
  16. }
    17.

我们使用 CountDownLatch 处理障碍同步。 这个等待的方法会阻塞主线程直到锁存计数变为 0。随着其它线程的运行（我们把这些其它线程表示为 future），每一个 future 都会调用 countDown 方法使锁存计数减 1。一但计数变为 0，所有的 future 就都已经运行到 waitForever 方法中了。

通过那一点，我们可以确保 throttler 是饱和的，内部有最大数量（maxCount）的线程。另一个线程试图进入 throttler 将导致异常。我们有一个确定的方式建立我们的测试，测试会有一个主线程进入 throttler。主线程可以恢复到这个点（门闩计数为 0 并等 CountDownLatch 释放等待线程）。

如果一些意想不到的事情发生，我们使用超时略高保障避免无限阻塞发生。如果这样的事情发生，我们的测试就失败了。这个超时不会影响到测试时间，除非发生意外情况，否则，我们都不应该等待。

结论

测试异步程序时，通常需要在具体的测试用例中指定多个线程之间的执行顺序。不使用任何同步策略的测试是不可靠的，测试结果有时成功有时失败。使用 Thread.sleep 降低了测试出错的概率，但没有完全解决这个问题。

在大多数情况下，当需要在测试中保证多个线程的执行顺序时，可以使用 CountDownLatch 代替 Thead.sleep。使用 CountDownlatch 的好处是通过它可以指定释放（保持）线程的时机，有两个优点：确保按顺序执行使测试结果更可靠；加快了测试程序的执行速度。即使对于普通的 waiting 操作，比如 waitForever 函数，尽管也可以使用 Thread.sleep(Long.MAX_VALUE) 这样的函数实现，但为了保证程序的健壮性最好不要这样做。

完整的代码可以在 GitHub 中找到。

分享题目：关于写异步代码测试用例的一些思考
链接地址：http://www.shufengxianlan.com/qtweb/news35/377785.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

解决方案知识

分类信息网站

做网站价格　　 　温江网站建设　　 　做手机网站　　 　成都响应式网站建设公司　　 　软文推广公司　　 　LED显示屏厂家　　 　成都微信开发　　 　四川国泰民安消防　　 　成都办公窗帘　　 　吉安网站建设　　 　绵竹网站建设　　 　大吉雪茄　　 　高端品牌网站建设　　 　成都企业网站建设　　 　成都网络公司　　 　成都名片印刷　　 　四川成都展柜定制厂家　　 　注册域名　　 　腾讯云免备案主机　　 　新都网站建设