无Spring环境下如何开发Pact Provider类？相关疑问解答

1. 提供者端是否需要mock客户端？ #

不需要。消费者端mock提供者是为了脱离真实服务完成自身测试，但提供者端的核心目标是验证自身服务是否符合消费者定义的契约——你只需要确保服务能正确响应契约中定义的请求，不需要关心客户端（消费者）的调用逻辑，客户端的mock是消费者自己的工作范畴。

2. 是否必须使用API的真实类？ #

不是必须，但建议优先使用。

• 如果你选择完整链路验证：启动真实的服务实例（比如你的HTTP接口服务），让Pact直接调用真实接口，这种情况需要用到API的真实类，好处是能覆盖从请求接收、业务处理到响应返回的全流程，避免逻辑层正确但API层出错的情况。
• 如果你选择核心逻辑验证：可以只测试处理请求的业务逻辑类，直接把契约中的请求参数传入逻辑类，验证返回结果是否符合契约，这种情况不需要完整的API类，但要注意后续还要单独验证API层和逻辑层的对接是否正常。

3. 非Spring环境下的提供者端核心要点 #

不管用什么技术栈，Pact提供者验证的核心逻辑和框架无关，抓住以下几点就不会遗漏：

• 契约解析与请求模拟：使用对应语言的Pact SDK读取pact文件，解析出每个交互的请求规则（HTTP方法、路径、参数、请求体等），然后模拟该请求调用你的服务或核心逻辑。
• 响应匹配验证：获取服务返回的响应后，用Pact的匹配器验证响应是否符合契约定义——包括状态码、响应头、响应体的结构、字段类型、指定值等。
• 测试状态管理：如果契约中的请求依赖服务的特定状态（比如查询某条数据需要先存在这条数据），要在每个验证用例前准备好测试数据，验证后清理，保证用例独立不干扰。
• 隔离性保障：每个契约交互的验证应该独立执行，避免不同用例之间的状态污染（比如数据库数据残留、内存缓存未清空）。

非Spring Java核心流程示例 #

// 1. 加载pact文件
Pact pact = PactReader.loadPact(new File("path/to/consumer-provider.pact"));

// 2. 启动你的非Spring服务（比如Jetty）
JettyServer server = new JettyServer();
server.start();

// 3. 遍历每个契约交互
for (Interaction interaction : pact.getInteractions()) {
    // 构造请求
    HttpRequest request = buildRequestFromInteraction(interaction);
    // 调用服务
    HttpResponse response = sendRequestToServer(request);
    // 验证响应
    ResponseMatchers.verifyResponse(response, interaction.getResponse());
}

// 4. 清理资源
server.stop();
cleanTestData();

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