在集成测试中,为了测试,将异步过程替换为异步过程是否有意义？

Question

在集成测试中,异步流程(方法,外部服务)构成了非常严格的测试代码.相反,我考虑了异步部分并创建了一个依赖项,并为了测试而将其替换为同步,这是一件"好事"吗？

通过用同步过程替换异步过程,我是不是在集成测试的精神下进行测试？我想我假设集成测试是指测试接近真实的东西.

Answer 1

好问题.

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

我经常使用"waitFor"方法进行轮询以查看是否已收到答案,如果没有,则在一段时间后超时.这个模式的一个很好的实现,虽然特定于Java,你可以获得要点,是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

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

这有几个优点：

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

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

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