xUnit异步测试必须返回Task且用async修饰，禁用void；断言需await而非Wait/Result；参数化测试用Theory+InlineData；应统一使用ConfigureAwait(false)避免死锁。
如何在 xUnit 中正确编写异步测试
xUnit 要求异步测试方法必须返回 Task（不能是 void），且需用 async 修饰。若写成 void，测试会“假成功”——即框架不等待异步操作完成就标记为通过。
- ✅ 正确写法：
public async Task MyTest() - ❌ 错误写法：
public async void MyTest()（xUnit 不识别，测试立即结束） - 断言异步代码时，直接
await调用，再用Assert；不要用.Wait()或.Result，否则可能死锁（尤其在 ui 或 ASP.net 同步上下文环境中） - xUnit 本身不提供
[TestCase]的异步变体，参数化异步测试需用[Theory]+[InlineData]，每个用例仍需返回Task
public class CalculatorTests { [Fact] public async Task AddAsync_ReturnsSum() { var result = await new Calculator().AddAsync(2, 3); Assert.Equal(5, result); } }NUnit 中 async 测试的兼容性陷阱
NUnit 3.0+ 支持 async Task 方法，但对 async void 也有一定容忍（不推荐）。关键差异在于：NUnit 允许测试方法返回 Task 或 void，但仅当返回 Task 时才真正等待异步完成。
- ⚠️ 若误写
async void，NUnit 可能不报错，但实际未等待异步逻辑，导致间歇性失败 - NUnit 的
[TestCase]和[Theory]均支持异步方法，只要签名是async Task - NUnit 默认使用同步上下文（SynchronizationContext）运行测试，某些依赖上下文的异步代码（如
await Dispatcher.InvokeAsync）在 NUnit 中比 xUnit 更容易“看似正常”，但这掩盖了线程模型问题 - 若测试中调用了需上下文的 API，建议显式配置
[RequiresThread]或用ConfigureAwait(false)避免隐式依赖
常见错误现象与定位方式
两类框架下最典型的失败表现不是抛异常，而是“测试绿了但逻辑没执行完”。比如 http 调用未发出去、数据库写入丢失、计时器未触发。
- 现象：
Assert没被调用，或断言值始终是默认值（如0、NULL） - 原因：测试方法返回
void或未await关键调用，框架提前退出 - 验证方法：在异步方法末尾加
console.WriteLine("done")，观察是否打印；或在被测异步方法内首行打日志，确认是否进入 - xUnit 报错提示较明确，例如
The test method returned void, but should return Task；NUnit 则更沉默，需靠行为观察
Should I use ConfigureAwait(false) in tests?
应该，尤其是在共享测试基类或封装通用异步断言逻辑时。测试运行器（如 visual studio Test Explorer、dotnet test）通常不提供有意义的同步上下文，保留默认 ConfigureAwait(true) 只会增加调度开销，还可能引发意外死锁。
- ✅ 推荐：所有可预见的非 UI/ASP.NET 场景下的测试异步调用，都加
.ConfigureAwait(false) - ❌ 不必：仅当测试明确模拟 UI 线程（如用
SingleThreadSynchronizationContext）时才保留上下文 - 注意：xUnit 和 NUnit 的测试发现与执行机制均不依赖 SynchronizationContext，所以默认忽略它是安全的
测试异步逻辑的核心不是选框架，而是守住“返回 Task + 正确 await + 避免上下文依赖”这三条线。漏掉任意一条，都可能让 bug 在 CI 上潜伏数周。