PACT提供者服务状态处理及数据库选型、数据注入相关问题咨询

1. 提供者API是否需要对接真实数据库 #

Pact要求打桩的是提供者的外部第三方依赖，比如调用的其他微服务、第三方API、外部存储服务等，避免外部服务不稳定影响契约测试结果，自身的数据库不属于需要强制打桩的范围，两种方案都可以选：

• 对接测试环境的真实数据库：更贴近生产运行逻辑，能同时验证数据读写逻辑的正确性，适合对测试覆盖率要求高的场景
• 打桩数据访问层：直接模拟数据查询结果，测试运行速度更快，适合需要频繁跑测试的CI流水线，但要保证桩逻辑和真实数据访问逻辑一致，避免测试过了生产环境出问题

2. 对接真实数据库时的测试数据注入方案 #

不建议调用提供者自身的接口添加测试数据，一方面如果接口有权限、参数校验逻辑会额外增加测试复杂度，另一方面如果新增数据的接口本身有bug，会导致契约测试失败，提升排查成本。
正确的做法是直接在提供者状态中间件的逻辑中注入数据：当中间件接收到Pact测试传递过来的Given条件时，直接通过ORM（EF Core、Dapper等）执行对应的数据插入语句，把匹配条件的测试数据写入测试库即可。

3. 完整的标准实现流程 #

推荐用容器化测试数据库的方案，实现成本最低、数据隔离性最好：

• 第一步：改造提供者服务，新增仅在Pact测试环境启用的提供者状态中间件，避免生产环境暴露状态操作接口，示例代码：

// Program.cs
if (builder.Environment.IsEnvironment("PactTest"))
{
    // 注册状态中间件，仅测试环境生效
    app.UseMiddleware<PactProviderStateMiddleware>();
}

// PactProviderStateMiddleware.cs 示例逻辑
public async Task InvokeAsync(HttpContext context)
{
    if (context.Request.Path.StartsWithSegments("/provider-states"))
    {
        var state = await context.Request.ReadFromJsonAsync<ProviderState>();
        if (state.State == "ID为123的用户存在")
        {
            // 直接操作测试库写入数据
            await _userDbContext.Users.AddAsync(new User { Id = 123, Name = "测试用户" });
            await _userDbContext.SaveChangesAsync();
        }
        context.Response.StatusCode = 200;
        return;
    }
    await _next(context);
}

• 第二步：测试启动前先通过Docker启动一个干净的测试数据库实例，所有测试数据都会写入这个临时实例
• 第三步：启动提供者服务，设置环境变量为PactTest，数据库连接字符串指向刚才启动的测试数据库，所有外部微服务依赖用WireMock或者Moq打桩，返回固定模拟结果
• 第四步：运行Pact提供者测试，测试框架会自动调用/provider-states接口准备对应状态，再发起请求验证契约
• 第五步：测试结束后直接销毁测试数据库容器，自动清理所有测试数据，不需要额外写脏数据清理逻辑

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