WebApplicationFactory：轻量级测试宿主，用错姿势会拖慢CI、污染状态
开门见山地说，WebApplicationFactory 从来就不是一个“教程型工具”。它本质上是一个轻量级的测试宿主，但用错了地方，麻烦可不小——拖慢CI流水线、污染测试状态，甚至让测试结果变得不可靠。先明确几个关键边界：别在每个测试方法里都去new一个实例，别指望它能自动继承生产环境的认证或配置，更别用它来测试前端交互。它的职责，到此为止。
创建实例时，程序集引用和入口类型必须严丝合缝
新手常踩的第一个坑，就是 new WebApplicationFactory 编译失败，或者运行时冷不丁抛出一个 System.IO.FileNotFoundException。问题根源往往很简单：测试项目没有正确引用被测项目的输出程序集。这里要的不是NuGet包，而是实实在在的项目引用（比如通过 dotnet add reference ../YourApp/YourApp.csproj 命令添加）。
再说入口类型。.NET 6及之后的版本默认使用 Program 类作为入口，而.NET 5及之前则习惯用 Startup 类。如果两者混用——比如测试项目目标是net6.0，而被测项目还是net5.0并使用了Startup——那么 WebApplicationFactory 就会找不到对应的类型符号，直接卡在起跑线上。
还有一个容易忽略的细节：隐式using（ImplicitUsings）。如果被测项目启用了 WebApplicationFactory 这个类型，让人摸不着头脑。
HttpClient.GetFromJsonAsync报“未找到方法”？缺包又缺命名空间
写完 factory.CreateClient()，顺手链式调用 client.GetFromJsonAsync，结果编译器直接报错。先别怪 WebApplicationFactory，问题通常出在环境上。
- 必须安装NuGet包：
System.Net.Http.Json - 必须添加命名空间：
using System.Net.Http.Json;
这个扩展方法底层调用了 SendAsync 并自动反序列化，但它不检查HTTP状态码。这意味着，如果接口返回401或403，它不会优雅地返回null，而是直接抛出一个 HttpRequestException。所以，别直接裸调，记得加上 EnsureSuccessStatusCode() 或者用try/catch包裹起来。
另外，如果API启用了 AddProblemDetails()（常见于全局异常中间件），默认的反序列化也会失败。因为此时的响应体是 ProblemDetails 结构，而不是你期望的 User 类型。这种情况下，更稳妥的做法是改用 client.GetAsync("/api/users")，然后手动读取 response.Content.ReadAsStringAsync() 来判断状态码和内容。
测试带[Authorize]的控制器？默认是匿名请求
需要警惕的是，WebApplicationFactory 创建的 HttpClient 默认是匿名请求。即便你在 Program.cs 里配置了JWT Bearer或Cookie认证，它也不会自动携带任何Token。
最简单的解决方案是手动设置请求头：
var client = factory.CreateClient();
client.DefaultRequestHeaders.Authorization = new("Bearer", "valid.jwt.token");
测试用的Token可以用 JwtSecurityTokenHandler 快速生成，注意设置好issuer、audience、签名密钥和有效期即可，无需依赖真实的身份提供商。切记，不要为了省事在多个测试间复用同一个Token——签名密钥变更或过期时间问题，很可能导致偶发性的测试失败。
当然，也可以选择更彻底的方式，比如自定义一个 TestAuthHandler 注入到测试服务容器里。但对于大多数场景来说，这有点杀鸡用牛刀了。记住一个原则：认证逻辑本身应该通过单元测试来覆盖，集成测试的核心是验证「有合法Token时能访问，没Token时被拒绝」这个契约。
想换用内存数据库？必须在ConfigureWebHost里覆盖服务
直接修改 IConfiguration，或者在测试方法里调用 services.Replace(...)，这些操作往往是无效的。原因在于，WebApplicationFactory 的服务注册发生在构建阶段，且顺序是固定的：先执行被测项目的 Program.cs，然后才执行你通过 WithWebHostBuilder 或重写 ConfigureWebHost 方法注入的逻辑。
正确的做法是在自定义的工厂类里重写 ConfigureWebHost 方法：
protected override void ConfigureWebHost(IWebHostBuilder builder)
{
builder.ConfigureServices(services =>
{
services.RemoveAll(typeof(DbContextOptions));
services.AddDbContext(options =>
options.UseInMemoryDatabase("TestDb"));
});
}
这里 RemoveAll 是关键一步，它能避免EF Core尝试同时注册SQL Server和InMemory提供程序而导致的冲突。另外，内存数据库的名称最好保持唯一（比如拼接一个Guid），防止多个并行运行的测试相互干扰。
这个原则同样适用于Hangfire、Redis Client等第三方服务：它们都必须在 ConfigureWebHost 阶段进行替换。指望修改 appsettings.Test.json 文件是行不通的，因为这些配置项通常在 Program.cs 的早期就被读取并使用了。
话说回来，使用 WebApplicationFactory 真正的难点，其实不在于怎么写，而在于树立清晰的边界意识。它测试的是「请求进入、中间件流转、控制器执行、响应返回」这一整条HTTP通路。至于Ja vaScript是否正确渲染、CSS是否生效、浏览器事件是否触发——这些都不归它管，那是Playwright等端到端测试框架的战场。在这里，我们只管好HTTP层的契约。
