如何测试异步方法是否真正异步执行？测试该特性是否合理？

我正在学习ASP.NET Web API框架及相关测试，想了解是否可以测试异步方法是否真正异步执行（比如会不会因为代码错误变成同步执行）。我的示例代码如下：

public class RepositoryBase<Tentity, Tcontext> : IRepositoryBase<Tentity> 
    where Tentity : class 
    where Tcontext : DbContext
{
    protected Tcontext _RepositoryContext;
    protected DbSet<Tentity> dbSet;

    public RepositoryBase(Tcontext context)
    {
        this._RepositoryContext = context;
        dbSet = _RepositoryContext.Set<Tentity>();
    }

    public async Task Create(Tentity entity)
    {
        await dbSet.AddAsync(entity);
    }
}

目前我在单元测试里只通过await repository.Create(testUser);验证功能正常，但没验证它的异步性。我不是质疑特定框架，而是想知道：

1. 能不能测试通用异步函数的异步性？
2. 测试这个特性是否有合理性？

一、测试异步性的合理性 #

完全有必要测试异步性，尤其是当异步行为是业务/性能要求的一部分时：

• 避免因代码失误（比如漏写await、误用.Result/.Wait()）导致异步方法退化同步，拖慢系统吞吐量
• 确保依赖的异步组件（比如EF Core的AddAsync）确实被异步调用，而非意外替换成同步实现

二、如何测试异步方法的异步性 #

1. 通过并行执行验证非阻塞特性 #

异步方法的核心是非阻塞，可以通过同时触发多个调用，观察它们是否并行执行（而非串行等待）：

[Test]
public async Task Create_ShouldExecuteAsynchronously()
{
    // 准备Mock上下文和仓库
    var mockContext = new Mock<DbContext>();
    var mockDbSet = new Mock<DbSet<Tentity>>();
    // 模拟AddAsync返回一个延迟完成的Task，方便观察并行
    mockDbSet.Setup(x => x.AddAsync(It.IsAny<Tentity>(), It.IsAny<CancellationToken>()))
             .Returns(() => Task.Delay(100).ContinueWith(_ => EntityEntry.Create<Tentity>(null)));
    mockContext.Setup(x => x.Set<Tentity>()).Returns(mockDbSet.Object);
    
    var repository = new RepositoryBase<Tentity, DbContext>(mockContext.Object);
    var testEntities = Enumerable.Range(0, 5).Select(_ => new Tentity()).ToList();

    // 记录开始时间
    var startTime = DateTime.Now;
    // 同时触发多个异步调用
    await Task.WhenAll(testEntities.Select(entity => repository.Create(entity)));
    var elapsedTime = DateTime.Now - startTime;

    // 如果是同步执行，5次100ms的操作至少需要500ms；异步并行的话，耗时应该接近100ms
    Assert.Less(elapsedTime.TotalMilliseconds, 200); // 留一点误差空间
}

2. 验证依赖的异步方法被调用 #

针对你的仓库代码，核心是确保dbSet.AddAsync被异步调用，而非同步替代（比如有人改成dbSet.Add(entity); return Task.CompletedTask;）。可以通过Mock验证：

[Test]
public async Task Create_ShouldCallAddAsync()
{
    var mockContext = new Mock<DbContext>();
    var mockDbSet = new Mock<DbSet<Tentity>>();
    mockContext.Setup(x => x.Set<Tentity>()).Returns(mockDbSet.Object);
    
    var repository = new RepositoryBase<Tentity, DbContext>(mockContext.Object);
    var testEntity = new Tentity();

    await repository.Create(testEntity);

    // 验证AddAsync被调用，而非同步的Add方法
    mockDbSet.Verify(x => x.AddAsync(testEntity, It.IsAny<CancellationToken>()), Times.Once);
    mockDbSet.Verify(x => x.Add(testEntity), Times.Never);
}

3. 注意：不要依赖线程ID判断异步 #

很多人会通过前后线程ID是否变化来判断异步，但这并不准确：

• 异步IO操作（比如EF Core的数据库操作）使用IOCP，可能在同一个线程上下文恢复（尤其是ASP.NET中）
• 异步方法的本质是非阻塞，而非“换线程”，所以线程ID变化不是必要条件

三、总结 #

• 可以测试通用异步函数的异步性，核心是验证非阻塞特性或依赖异步方法的调用
• 测试异步性是合理的，能提前发现代码退化问题，保障系统性能

内容的提问来源于stack exchange，提问作者White Head Ice Prince