c# 如何在单元测试中测试异步和并发代码

xUnit/NUnit支持async Task测试方法，需返回Task且标记async；避免async void；并发测试可用Task.WhenAll配合同步点模拟竞态。

如何让 xUnit / NUnit 正确运行 async Task 测试方法

直接写 async Task 方法但不 await，测试框架会认为它“立刻完成”，实际异步逻辑可能没执行完就判通过。xUnit 从 2.0 起原生支持 async Task，NUnit 3.0+ 也支持，但必须满足两个条件：返回类型是 Task（不能是 void），且测试方法本身标记 async。

• public async Task MyTest() { await SomeAsyncOperation(); } ✅ 正确
• public async void MyTest() { ... } ❌ 框架无法等待，测试可能提前结束
• public Task MyTest() { return SomeAsyncOperation(); } ✅ 可行，但失去 await 的调试和异常传播优势

异常处理也不同：await 后抛出的异常会被框架捕获并显示为测试失败；而直接 return Task 时，未观察的异常可能被吞掉或导致进程崩溃（尤其在 .net Framework 上）。

如何模拟并发调用并验证竞态条件

真实并发很难复现，所以得主动制造竞争窗口。常用做法是用 Task.WhenAll 启动多个相同操作，再配合 Task.Delay 或手动同步点（如 ManualResetEvent）控制执行节奏。

public async Task ConcurrentUpdate_ShouldNotLoseChanges() {     var counter = new Counter();     var tasks = Enumerable.Range(0, 100)         .Select(_ => Task.Run(() => {             for (int i = 0; i < 10; i++)                 counter.Increment(); // 假设这个方法不是线程安全的         }));     await Task.WhenAll(tasks);     Assert.Equal(1000, counter.Value); // 很可能失败，暴露问题 }

注意：Task.Run 不等于“真正多线程”——它只是把工作调度到线程池，但对共享状态的访问仍需同步。如果测试总是通过，大概率是因为并发度不够或操作太快，可加 await Task.Delay(1) 在关键位置放大竞争窗口。

如何测试 IAsyncEnumerable 或流式异步操作

不能用普通 foreach，必须用 await foreach，且测试框架需运行在支持 C# 8+ 的环境中。常见错误是忘记 await 导致枚举器没真正消费。

• 正确：await foreach (var item in GetAsyncstream()) { ... }
• 错误：foreach (var item in GetAsyncStream()) { ... } → 编译不过或静默跳过
• 验证空流：Assert.Empty(await GetAsyncStream().ToListAsync());（需引用 System.linq.Async）

如果被测方法返回 IAsyncEnumerable 但内部有延迟或分页逻辑，可在测试中插入 await Task.Delay 模拟网络抖动，再断言是否按预期分批返回。

为什么 Thread.Sleep 在异步测试里是坏味道

它会阻塞当前线程，而单元测试通常跑在线程池线程上，无谓消耗资源；更严重的是，在某些上下文（如 ASP.NET Core 集成测试）中可能引发死锁。所有等待都该用 await Task.Delay 替代。

• Thread.Sleep(100); ❌ 阻塞、不可取消、难 mock
• await Task.Delay(100); ✅ 非阻塞、支持 CancellationToken、可被 TimeProvider（.NET 8+）统一控制

.NET 8 引入了 TimeProvider 抽象，允许在测试中冻结/快进时间，彻底替代硬编码的 Delay。但目前多数项目还没升级，所以现阶段最稳妥的做法仍是用短而明确的 Task.Delay，并确保超时值足够大以覆盖最慢路径，又不至于拖慢整个测试套件。