WebApplicationFactory集成测试用途及发布流水线运行相关问题咨询

1. WebApplicationFactory 在集成测试中的作用与适用场景 #

先纠正认知偏差：WebApplicationFactory 是 ASP.NET Core 官方内置的集成测试工具，并非仅用来模拟外部服务，模拟外部依赖只是它的附加能力之一。
它的核心价值是在测试进程内启动一个内存级 Web 服务实例，不需要真实部署到 Kestrel/IIS、不需要占用实际端口，就能完整复现 Web API 的全链路运行逻辑：从路由匹配、模型绑定、过滤器、中间件执行，到 DI 容器依赖注入、业务逻辑运行、响应序列化返回，完全符合集成测试「验证多组件协同运行逻辑」的核心要求。
简单 Web API 集成测试非常推荐使用它，原因如下：

• 官方原生适配 ASP.NET Core 所有配置规则，不需要手动处理服务启动、端口占用、进程销毁等琐碎逻辑，零额外成本就能搭建完整集成测试环境
• 内存服务的执行效率远高于真实启动外部服务的测试方案，执行速度接近单元测试，不会拖慢流水线运行效率
• 可通过重写 ConfigureWebHost 方法灵活替换 DI 容器中的外部依赖（比如把生产数据库替换为测试用内存库、把第三方接口替换为模拟实现），在保证测试环境隔离性的同时，完整覆盖核心业务链路
  如果不使用它，你要么只能绕开 HTTP 层直接调用控制器方法（无法覆盖路由、模型绑定等边缘逻辑，不属于完整的集成测试），要么需要自己实现服务启动、销毁的逻辑，反而增加不必要的维护成本。

2. 发布流水线中的运行逻辑与配置隔离性 #

首先给出明确结论：自定义 WebApplicationFactory 的所有配置修改逻辑完全不会影响到实际要发布的应用的配置，所有变更仅作用于测试上下文，和生产部署的应用完全隔离。
运行逻辑如下：

• 测试项目是独立的程序集，和要发布的 Web API 项目是编译隔离的，测试代码的任何逻辑都不会修改 API 项目本身的文件、编译输出的 dll 内容
• 无论本地运行还是 Azure 流水线运行测试，都是在独立的测试进程中，通过 WebApplicationFactory 加载 API 项目代码、初始化内存服务实例，你重写的 appsettings 配置、依赖替换规则都只在这个测试进程的内存中生效，不会修改任何物理文件
• Azure 流水线的集成测试阶段是独立步骤，测试执行过程不会触碰你后续要发布的应用包的任何内容。只有测试全部通过后，流水线才会执行后续发布流程，发布的是原本使用生产环境配置的应用包，完全不受测试逻辑影响。
  如果你后续还有部署到测试环境后的端到端测试，那部分测试是和部署的测试环境服务交互，和 WebApplicationFactory 实现的集成测试完全隔离，不会互相干扰。

内容的提问来源于stack exchange，提问作者u1234