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

来源:这里教程网 时间:2026-02-21 17:38:53 作者:

如何让 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<t></t>
或流式异步操作

不能用普通

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<t></t>
但内部有延迟或分页逻辑,可在测试中插入
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
,并确保超时值足够大以覆盖最慢路径,又不至于拖慢整个测试套件。

相关推荐