异步系统的两种测试方法

互联网软件系统一直随着需求、用户量上升等等的缘由在演进，以求适应更复杂的业务场景，更高的性能要求等等。软件演进方式各类各样，系统异步化即为其中一种。

通常的，对于那些实时性要求不高，但却计算密集或者须要处理大数据量的耗时较长的任务，或是有较慢 I/O 的任务，选择异步化是一个不错的选择。在系统层面，像引入消息中间件来解耦系统，将耗时长的任务放在中间件后异步执行。在方法层面，像把耗时较长的任务放到其余线程中去异步执行。

与测试同步系统或方法不一样，当咱们测试异步系统（端到端测试、集成测试）或异步方法的时候（单元测试），因为测试线程不会被异步任务线程阻塞而让测试变得不可控，几率性失败，以单元测试为例，这样写异步测试是不稳定的：

@Test
public void testAsynchronousMethod() {
    callAsynchronousMethod();
    assertXXX(...);  //异步任务可能仍未完成，这时assert可能会失败
}
复制代码

###异步任务的两种类型：

• 异步任务执行后对任务发起方或调用方有感知，好比发出一个事件或通知
• 异步任务执行后对任务发起方或调用方没有感知，只是改变了系统中的某些状态

对异步任务的测试也分以上两种类型讨论。对于第一种，咱们能够采用监听方式测试：

import org.junit.Before;
import org.junit.Test;

public class ExampleTest {
    private final Object lock = new Object();

    @Before
    public void init() {
        new Thread(new Runnable() {
            public void run() {
                synchronized (lock) {  //得到锁
                    monitorEvent();    //监听异步事件的到来
                    lock.notifyAll();  //事件到达，释放锁
                }
            }
        }).start();
    }

    @Test
    public void testAsynchronousMethod() {
        callAsynchronousMethod();  //调用异步方法，须要较长一段时间才能执行完，并触发事件通知

        /** * 事件未到达时因为init已经得到了锁而阻塞，事件到达后因init中的锁释放而得到锁， * 此时异步任务已执行完成，能够放心的执行断言验证结果了 */
        synchronized (lock) {
            assertTestResult();
        }
    }
}
复制代码

这里的前提是事件通知会到来并被监听到，可要是不来呢（好比异常任务执行失败了）？咱们就干等吗，其实咱们还能够在测试中引入超时机制，这也引出了第二种类型的异常测试（能够称之为轮询方式），假设咱们有以下一个异步系统，应用发消息到 NSQ 消息中间件，一个待测试的 Job 监听这个消息并在消息到达后处理消息：

那咱们怎么测试呢，站在端到端测试的角度，能够测试从应用到 Job 的链路，消息是应用直接构造的 NSQ 消息，也能够是 Mysql binlog 经转化后构造的 NSQ 消息；站在集成测试的角度，咱们能够缩小测试范围，直接在测试中构造 NSQ 消息，测试从消息中间件到 Job 的链路。长链路测试耗时长，且写测试前须要了解具体应用的消息触发逻辑，写测试也比较慢，无形中增长了不少测试成本。因此对于这样的系统，咱们能够采用集成测试方法来测。

@Test
public void testAsynchronousJob() throws Exception {
    String msg = buildNsqMsg();    //构造NSQ消息
    nsqClient.send(TOPIC, msg, false);	//发送Nsq消息

    with().pollInterval(ONE_HUNDRED_MILLISECONDS).  //100ms后开始检查
            and().with().pollDelay(10, MILLISECONDS).  //此后每隔10ms检查一次
            await("description").  //描述信息
            atMost(1L, SECONDS).   //1s超时时间
            until(() -> xxxService.getState() == "changed");  //业务相关的断言逻辑
}
复制代码

上述测试咱们引入了 awaitility 工具类来作轮询操做，一个靠谱的轮询至少包含如下特性：

• 超时机制，不可能一直轮询
• 首次延迟轮询
• 轮询频率

最后，咱们来讨论下测试结果可靠性问题。

假设一个异步系统采用轮询方式测试，触发异步任务后，当在两次轮询中间系统状态由于某些缘由出现了抖动，下一次轮询时轮询方式可能会误觉得异步操做还未完成或出现了异常，从而致使测试结果误判：

相对的，监听方式是不存在这样的问题的，只要系统状态改变，监听中的测试能立马感知到，并做出可靠的测试结果：

不少异步系统对外是没有回调的，这时候只能使用轮询方式测试异步任务，而轮询测试的可靠性取决于待测系统的可靠性。

但是，一个周期性执行的可靠系统一样会遇到上述问题，测试会由于代码周期性执行，系统状态周期性改变而变得不可靠。对于这样的系统，咱们能够作一些可测性改造。将业务逻辑和周期执行逻辑剥离，并增长一个能够调用业务逻辑的入口，好比一个 restful 接口，这样测试时能够准确控制业务逻辑的执行时机和频率，也就能够可靠的测试了。

有赞已经在一些异步 Job 中采用上述轮询方式测试，咱们在测试中主要碰到了两类 Job，一类是会和 Elasticsearch 搜索引擎交互的，因为 Elasticsearch 的刷新机制（有赞出于性能缘由设置为 5 秒刷新一次数据），轮询方式由于测试时间太长而很局限，除非提升 Elasticsearch 的刷新频率；另外一类则是跟 Mysql、Redis 交互的 Job，这类 Job 的测试能够工做的很好，测试基本能够在 150 毫秒内完成，也就意味着能够像普通测试同样置入持续集成的构建中了。