PHP 契约测试怎么做

PHP 契约测试实战指南：从入门到落地，告别“联调翻车”

目录导读

1. 为什么你的PHP微服务总在联调时“爆雷”？
2. 契约测试 vs 单元测试 vs 集成测试：到底该选谁？
3. PHP契约测试核心工具链：Pact与PhpSpec/ Pest实战
4. 手把手：用Pact编写消费者驱动契约（消费者端）
5. 手把手：用Pact验证提供者（提供者端）
6. 代码示例：Laravel框架下的契约测试完整流程
7. 契约测试的坑与最佳实践（含CI/CD集成）
8. 常见问题问答（FAQ）

---

为什么你的PHP微服务总在联调时“爆雷”？

想象一个场景：你的订单服务（PHP）需要调用用户服务的 GET /api/users/{id}，你本地Mock了用户服务，自测通过，然而上线前联调，用户服务返回的字段名从 user_name 改成了 name，你的代码瞬间崩盘，这不是代码Bug，而是“契约断裂”。

在微服务架构中，服务间依赖的不是代码，而是接口约定（契约），单元测试只验证本地逻辑，集成测试往往需要搭建真实环境且速度极慢，契约测试（Contract Testing）则专门验证“服务间通信协议是否一致”，它不启动整个应用，只针对接口请求/响应格式做校验。

核心价值：把“联调阶段”的被动发现问题，前置到“开发阶段”的主动验证,节省数天乃至数周的沟通成本。

契约测试 vs 单元测试 vs 集成测试：到底该选谁？

类型	验证范围	运行速度	环境依赖	适用场景
单元测试	单一函数/方法	极快	无	本地算法、逻辑分支
契约测试	单个服务间接口	快	无真实网络	服务间API约定
集成测试	多服务+数据库+网络	慢	复杂	关键业务链路

契约测试是“轻量级集成测试”，它不启动HTTP服务器，而是以“消息体”格式模拟请求响应，如果你使用的是 Guzzle 或 Symfony HttpClient,契约测试可以直接基于这些客户端封装。

PHP契约测试核心工具链：Pact与PhpSpec/ Pest实战

目前PHP生态最成熟的是 Pact（由Pact Foundation维护）：

• pact-php：官方客户端,支持消费者与提供者。
• Pest 或 PHPUnit：作为测试运行器。
• PhpSpec：适合BDD风格,但Pact官方推荐PHPUnit。

安装：

composer require pact-foundation/pact-php --dev
composer require pestphp/pest --dev  # 可选

核心流程：

1. 消费者端：定义期望的请求/响应，生成 pact 文件（JSON）。
2. 共享契约文件：通过Git仓库或Pact Broker存放。
3. 提供者端：读取契约文件,验证实际API是否符合。

手把手：用Pact编写消费者驱动契约（消费者端）

假设你的订单服务（消费者）需要调用用户服务（提供者）,在订单服务的测试中：

use Pact\Consumer\ConsumerClient as PactClient;
use PHPUnit\Framework\TestCase;
class UserConsumerTest extends TestCase {
    public function testFetchUserContract() {
        $client = new PactClient('order-service', 'user-service');
        $client->given('user exists')
               ->uponReceiving('a request for user by id')
               ->withRequest('GET', '/api/users/123')
               ->willRespondWith(200, ['Content-Type' => 'application/json'], [
                   'id' => 123,
                   'name' => 'Tom',
                   'email' => 'tom@test.com'
               ]);
        // 实际调用真实API（Pact会拦截或模拟）
        $response = $this->callYourHttpClient('/api/users/123');
        $this->assertEquals(200, $response->getStatusCode());
        $client->verify(); // 验证响应是否匹配预期
    }
}

关键点：消费者测试中的“预期响应”不是Mock，而是真实请求的“快照”，Pact会记录该请求，并生成 user_service_consumer_order_service.json 契约文件。

生成契约文件：

./vendor/bin/pact-php generate-contracts

手把手：用Pact验证提供者（提供者端）

在用户服务（提供者）的测试中,添加：

use Pact\Provider\ProviderClient;
class UserProviderTest extends TestCase {
    public function testUserEndpointSatisfiesPact() {
        $pact = new ProviderClient('user-service', 'contracts/');
        $pact->setPactFile('path/to/user_service_consumer_order_service.json');
        // 启动你的App（PHP内置服务器或Spin-up）
        $pact->withProviderState('user exists')
             ->setUp(function() {
                 // 初始化测试数据库或数据
                 putenv('USER_ID=123');
             })
             ->verify();
    }
}

运行提供者验证：

./vendor/bin/pact-php verify --provider=user-service

如果用户服务改动导致字段变更（如 name 改为 full_name），提供者验证会失败并提示“与契约不匹配”。

代码示例：Laravel框架下的契约测试完整流程

Laravel场景：订单服务（消费者）通过 Guzzle 调用用户服务。

消费者端（订单服务）：

// tests/Feature/UserContractTest.php
use Pact\Consumer\InteractionBuilder;
use Pact\Consumer\MockServer;
use PHPUnit\Framework\TestCase;
class UserContractTest extends TestCase {
    public function testFetchUser() {
        $mockServer = new MockServer('user-service', '1.0.0');
        $builder = new InteractionBuilder();
        $interaction = $builder->given('user exists')
            ->uponReceiving('get user details')
            ->with(['method' => 'GET', 'path' => '/api/users/1'])
            ->willRespondWith(['status' => 200, 'body' => ['name' => 'Alice']]);
        $mockServer->addInteraction($interaction);
        $mockServer->start();
        $client = new \GuzzleHttp\Client(['base_uri' => $mockServer->getUri()]);
        $response = $client->get('/api/users/1');
        $this->assertEquals('Alice', json_decode($response->getBody())->name);
        $mockServer->verify();
        $contract = $mockServer->writePact('order-service', 'user-service', '1.0.0');
        echo "Contract generated: " . $contract;
    }
}

提供者端（用户服务）：

// tests/Feature/VerifyUserPactTest.php
use Pact\Provider\PactBroker;
use Pact\Provider\Verifier;
class VerifyUserPactTest extends TestCase {
    public function testVerifyAgainstBroker() {
        $verifier = new Verifier();
        $broker = new PactBroker('https://your-pact-broker.com');
        $result = $verifier->verify([
            'provider' => 'user-service',
            'providerBaseUrl' => 'http://localhost:8000',
            'pactBroker' => $broker,
            'publishVerificationResult' => true,
        ]);
        $this->assertTrue($result);
    }
}

契约测试的坑与最佳实践（含CI/CD集成）

常见坑：

1. 契约文件不更新：消费者改接口后忘记重新生成Pact文件。
2. 过多状态：given 状态太多，Provider测试爆炸,建议只保留核心状态。
3. 网络依赖：Pact Broker需要网络，离线环境下无法运行,可改为Git仓库存储契约文件。

最佳实践：

• CI/CD中自动运行：消费者测试 → 生成契约 → 上传至Broker；提供者测试 → 从Broker拉取最新契约 → 验证 → 发布验证结果。
• 契约版本管理：使用 ConsumerVersion 和 ProviderVersion 标记,Broker自动比对兼容性。
• 不测业务逻辑：契约测试只关心“请求/响应格式”,不验证提供者内部算法。
• 配合Api Platform或Swagger：契约测试可与OpenAPI文档同步,减少维护成本。

GitHub Actions 示例：

name: Contract Tests
on: [push]
jobs:
  consumer:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: composer install
      - run: vendor/bin/phpunit --testsuite ConsumerContract
      - run: vendor/bin/pact-php generate-contracts
      - uses: pact-foundation/pact-broker/upload@v2
        with:
          broker-url: ${{ secrets.PACT_BROKER_URL }}
          pact-file: contracts/
          consumer-version: ${{ github.sha }}

常见问题问答（FAQ）

Q1：契约测试能完全替代集成测试吗？ 不能，契约测试覆盖“接口约定”，但不覆盖“数据库事务”“缓存一致性”“跨服务分布式事务”等，建议：高价值业务链路用集成测试,日常服务间调用用契约测试。

Q2：如果接口是异步消息（Kafka）能用Pact吗？ Pact支持 Message Pact，针对异步事件流也有契约验证方案，但PHP生态支持较弱，可用 PHPUnit 结合 Mockery 模拟队列做轻量验证。

Q3：Pact Broker需要收费吗？ Pact Broker有开源免费版（Docker自托管），也有PactFlow商业版提供UI和高级功能,中小团队推荐自建Docker版。

Q4：契约测试文件应该放在哪个项目仓库？ 推荐放在消费者项目仓库中，通过Broker共享，避免放在独立仓库造成“三处维护”问题。

Q5：处理版本兼容性时，能否只验证消费者使用的字段？ 可以，Pact默认就是“消费者期望什么，提供者只需验证这些字段”，提供者多余字段不影响验证，这符合“松弛契约”理念。

---

契约测试不是银弹，但它是微服务治理的“交通规则”，在PHP项目中，借助Pact工具链，你可以在每个迭代里快速确认“我的服务不会因为对端改动而悄悄碎裂”，掌握它，你将告别“联调噩梦”，让团队交付节奏提速一倍，立即在下一个Sprint中挑一个核心接口试点,用30分钟跑通第一个契约测试吧！