在集成测试中，为了测试而将异步流程替换为同步流程是否有意义？

Question

在集成测试中，异步流程（方法、外部服务）会产生非常困难的测试代码。相反，如果我为了测试而分解出异步部分并创建一个依赖项并将其替换为同步部分，这会是一件“好事”吗？

通过用同步流程替换异步流程，我不是本着集成测试的精神进行测试吗？我想我假设集成测试是指接近真实情况的测试。

Answer 1

好问题。

在单元测试中，这种方法是有意义的，但对于集成测试，您应该测试真实的系统，因为它在现实生活中的行为。这包括任何异步操作及其可能产生的任何副作用 - 这是最有可能存在错误的地方，并且可能是您应该集中测试而不是将其排除在外的地方。

我经常使用“waitFor”方法，轮询以查看是否已收到答案，如果没有，则在一段时间后超时。这种模式的一个很好的实现是 JUnitConditionRunner。例如：

conditionRunner = new JUnitConditionRunner(browser, WAIT_FOR_INTERVAL, WAIT_FOR_TIMEOUT);   

protected void waitForText(String text) {
    try {
        conditionRunner.waitFor(new Text(text));
    } catch(Throwable t) {
        throw new AssertionFailedError("Expecting text " + text + " failed to become true. Complete text [" + browser.getBodyText() + "]");
    }
}

Answer 2

我们有许多自动化单元测试，它们发送异步请求并需要测试输出/结果。我们处理它的方式是实际执行所有测试，就好像它是实际应用程序的一部分一样，换句话说，异步请求保持异步。但是测试工具同步运行：它发送异步请求，休眠一段时间（我们期望生成结果的最长期限），如果仍然没有结果可用，则测试已经失败了。有回调，因此在几乎所有情况下，测试都会在超时到期之前被唤醒并继续运行，但超时意味着失败（或预期性能的变化）不会停止/停止整个测试套件。

这有几个优点：

• 单元测试非常接近应用程序的实际调用模式
• 不需要新的代码/存根来使应用程序代码（正在测试的代码）同步运行
• 隐式测试性能：如果测试休眠了周期太短，则某些性能特征发生了变化，需要查看

最后一点可能需要少量解释。性能测试很重要，并且经常被排除在测试计划之外。这些单元测试的运行方式最终会比我们重新安排代码以同步执行所有操作花费更长的时间（运行时间）。然而，通过这种方式，可以隐式测试性能，并且测试更忠实于它们在应用程序中的使用情况。另外，我们所有的消息队列基础设施都经过“免费”测试。

编辑：添加了有关回调的注释

Answer 3

你在测试什么？你们班级对某些刺激的反应是什么？在什么情况下，合适的模拟不能完成这项工作？

Class Orchestrator implements AsynchCallback {

    TheAsycnhService myDelegate;  // initialised by injection

    public void doSomething(Request aRequest){
          myDelegate.doTheWork(aRequest, this)
    }

    public void tellMeTheResult(Response aResponse) {
          // process response
    }
}

您的测试可以执行类似的操作，

 Orchestrator orch = new Orchestrator(mockAsynchService);

 orch.doSomething(request);

 // assertions here that the mockAsychService received the expected request

 // now either the mock really does call back
 // or (probably more easily) make explicit call to the tellMeTheResult() method

 // assertions here that the  Orchestrator did the right thing with the response

请注意，这里没有真正的异步处理，并且模拟本身除了允许验证正确请求的接收之外不需要任何逻辑。对于 Orchestrator 的单元测试来说，这已经足够了。

在测试 BPEL 流程时，我使用了这个想法的变体 WebSphere 进程服务器。