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，并确保超时值足够大以覆盖最慢路径，又不至于拖慢整个测试套件。
