async方法覆盖率低的主因是测试未真正等待：测试方法须为async Task并用await调用，禁用void或.Result/.Wait()；需确认覆盖率工具支持状态机、PDB存在、Mock引入真实异步点、避免并发共享状态。
async方法里await后代码没被覆盖？检查测试是否真正等待
C# 异步方法的覆盖率低，最常见的原因是测试方法没真正等待 async 被测方法完成。比如写了个 void 测试方法，或者用了 Task.Run(...).Wait() 但没捕获异常，导致后续逻辑根本没执行。
- 测试方法必须声明为
async Task，不能是void或Task同步调用 - 必须用
await调用被测async方法，而不是.Result或.Wait()（会死锁或掩盖异常） - 若被测方法内部有
ConfigureAwait(false)，测试中一般无需特殊处理；但若用了ConfigureAwait(true)且在 UI/ASP.NET 同步上下文里跑测试，可能卡住——xUnit/NUnit 默认无同步上下文，通常安全
示例错误写法：
[Fact]
public void ShouldDoSomething() // ❌ 返回 void，无法 await
{
var result = _service.DoWorkAsync().Result; // ❌ 阻塞 + 可能死锁
}正确写法：
[Fact]
public async Task ShouldDoSomething() // ✅
{
var result = await _service.DoWorkAsync(); // ✅
Assert.NotNull(result);
}覆盖率工具不识别async状态机生成的代码？确认工具支持 C# 7.0+ 状态机
主流覆盖率工具（如 Coverlet、OpenCover、dotCover）对 async 方法的支持取决于是否能解析编译器生成的状态机类型（<methodname>d__N</methodname> 类型和 MoveNext 方法）。老版本 Coverlet（include-source 的配置，容易漏掉 await 后的分支。
- 使用 Coverlet 时，确保
coverlet.msbuild版本 ≥ 3.1，并在.csproj中启用源码映射：<PropertyGroup> <CollectCoverage>true</CollectCoverage> <CoverletOutputFormat>opencover</CoverletOutputFormat> <IncludeSource>true</IncludeSource> </PropertyGroup>
- 不要依赖 IDE 内置覆盖率（如 Visual Studio Live Unit Testing），它对
async分支识别不稳定；优先用 CLI + Coverlet 生成 OpenCover 报告再导入 ReportGenerator - 若发现
MoveNext方法显示“未覆盖”，但业务逻辑明明执行了，大概率是 PDB 符号文件没随 DLL 一起被覆盖率工具读取——检查构建输出目录是否包含.pdb文件
Mock异步依赖时返回Task.FromResult却没触发await分支？用Task.CompletedTask或真实延迟
测试中常对 IHttpClientFactory、IDbContext 等异步依赖做 Mock，但如果只返回 Task.FromResult(...)，编译器可能将整个 async 方法优化为同步执行（尤其当方法体内没有真正的异步点），导致 await 后续代码在状态机中不被视为独立可覆盖路径。
- 对纯返回值场景，用
Task.FromResult(...)没问题；但若想验证await后逻辑（比如日志、转换、条件判断），建议至少插入一个非内联的异步点：- 用
Task.Run(() => value)（注意线程切换开销） - 或更推荐：用
Task.Delay(1).ContinueWith(_ => value)，确保进入状态机调度 - NUnit/Xunit 中也可直接用
Task.CompletedTask+ 单独赋值变量模拟中间状态
- 用
示例（确保 await 分支被识别）：
_httpClient.GetAsync("api/data")
.Returns(Task.Delay(1).ContinueWith(_ => new HttpResponseMessage
{
Content = new StringContent("{\"id\":1}", Encoding.UTF8, "application/json")
}));并发执行多个async测试导致覆盖率抖动？避免共享状态与静态资源
当多个 async 测试并行运行（如 xUnit 默认并行），若它们共用静态缓存、单例服务或未隔离的内存数据库（如 InMemoryDatabase），可能因竞态导致某些分支未执行、异常被吞、或测试提前结束——最终表现为覆盖率忽高忽低，特别是 catch 块或 finally 里的日志记录。
- 所有测试应使用独立实例：每个
[Fact]创建新ServiceCollection+ServiceProvider，避免static服务注入 - 若测试涉及时间敏感逻辑（如
Task.Delay(100)），改用可控的IAsyncTimer抽象并 Mock，防止超时失败或跳过分支 - Coverlet 的
--no-build模式下若 DLL 已存在但 PDB 未更新，也会误报未覆盖——CI 中务必保证 clean build
async 方法的覆盖率陷阱不在语法本身，而在执行流是否真实经过所有状态机跃迁点。最常被忽略的是：你以为 await 完了，其实线程早被回收了，或者 Mock 太“顺滑”，把异步变成了假异步。
