【Go 测试之道】07 微服务的“握手”协议：用契约测试解耦集成

大家好，我是Tony Bai。

欢迎来到《Go 测试之道：从测试金字塔到高级实践》的第七讲。

在过去的几讲中，我们已经为“短链接”服务构建了一个相当坚固的测试金字塔。我们用单元测试保证了每个“零件”的质量，用 Testcontainers 支持的集成测试，确保了我们的服务与它所依赖的基础设施（PostgreSQL, Redis）能够完美协作。

至此，对于一个单体应用来说，我们的测试体系似乎已经足够完善。

但，欢迎来到微服务的世界。

回忆一下01讲中我们的架构蓝图，有一个被我们长期“忽略”的依赖——**外部用户服务 (User Service)**。假设这个服务由另一个团队（我们称之为“用户团队”）负责维护。现在，我们需要在创建短链接时，调用它的 API 来验证用户权限。

一个直接的想法是，为这个场景也写一个集成测试。但这立刻会把我们拖入“集成测试地狱”：

• 环境依赖： 我们需要“用户团队”提供一个稳定、可用的测试环境。如果他们的服务挂了，我们的 CI/CD 就会失败。

• 数据不同步： 他们的测试环境数据可能随时变化，导致我们的测试结果不可预测。

• 沟通成本高： 每次他们的 API 发生（甚至是微小的）变更，都需要通知我们，否则我们的测试就会“悄无声息”地失败。

• 反馈周期长： 运行这种跨服务的重量级集成测试，极其缓慢。

传统的集成测试，在微服务架构下，变成了一个脆弱、昂贵且低效的瓶颈。我们需要一种全新的“解耦”测试思想。这，就是契约测试 (Contract Testing)。

什么是契约测试？—— 一场“异步”的集成测试

契约测试的核心思想，简单而颠覆：

不再将两个服务拉到一起进行端到端的“联调”，而是通过一份双方都认可的“契约 (Contract)”文件，让消费者 (Consumer) 和提供者 (Provider) 可以各自独立、异步地进行测试。