NUnit框架中Assert.ThatAsync嵌套断言失效问题解析

问题背景

在NUnit测试框架中，异步断言方法Assert.ThatAsync在与嵌套断言结合使用时会出现异常行为。具体表现为当测试失败时，无法正确显示堆栈跟踪和实际失败信息，甚至在某些情况下会错误地报告"Multiple failures"。

问题复现

考虑以下测试代码示例：

await Assert.ThatAsync(FailingDelayedAssertion, Throws.InstanceOf<AssertionException>()
    .With.Message.Contain("milliseconds delay")
    .With.Message.Contain("property ExpectedType.My:"));

其中FailingDelayedAssertion是一个调用Assert.ThatAsync并抛出AssertionException的方法。这种情况下，测试会报告失败，但不会显示预期的堆栈跟踪和详细的失败信息。

根本原因分析

经过深入分析，发现问题根源在于ExceptionHelper.RecordExceptionAsync方法的实现。与同步版本不同，异步版本没有调用TestExecutionContext.IsolatedContext。这导致顶层断言和嵌套断言共享同一个CurrentContext，进而共享Result和Assertions.Count。

这种共享状态会导致：

1. 断言结果被错误地合并
2. 堆栈跟踪信息丢失
3. 可能产生"Multiple failures"的错误报告

影响范围

该问题不仅影响Assert.ThatAsync，还影响其他异步断言方法如Assert.ThrowsAsync等。这些方法同样没有使用TestExecutionContext.IsolatedContext来隔离执行上下文。

解决方案对比

有趣的是，如果使用同步版本的断言方法，问题就不会出现：

Assert.That(FailingDelayedAssertion, Throws.InstanceOf<AssertionException>()
    .With.Message.Contain("milliseconds delay")
    .With.Message.Contain("property ExpectedType.My:"));

这是因为同步版本正确地使用了隔离上下文，确保了每个断言都有独立的执行环境。

技术启示

这个问题揭示了异步测试中上下文隔离的重要性。在同步测试中，执行流程是线性的，上下文管理相对简单。但在异步环境中，执行流程可能交错，必须确保每个异步操作都有自己独立的上下文，避免状态污染。

最佳实践建议

在NUnit修复此问题前，建议开发者：

1. 尽量避免在异步断言中嵌套其他断言
2. 对于复杂的异步断言场景，考虑拆分为多个独立测试
3. 必要时可以使用同步断言作为临时解决方案
4. 关注NUnit的更新，及时应用修复版本

总结

异步测试中的上下文隔离是保证测试可靠性的关键因素。NUnit框架中的这个问题提醒我们，即使是成熟的测试框架，在异步编程模型下也可能存在微妙的边界情况。理解这些底层机制有助于我们编写更健壮的测试代码，并在遇到问题时能够快速定位原因。