集成测试脚手架：面向微服务架构的集中式测试方法

Source: Dev.to

现代测试的盲点

典型的微服务设置已经包括：

• 单元测试 → 稳固且快速
• 契约测试 → 确保模式兼容性
• 端到端测试 → 覆盖完整的 UI 工作流

那么故障仍然发生在哪里？

它们不是发生在单个服务中，而是发生在服务之间。

示例

• 数据在多个转换过程中失去精度
• OAuth 令牌在某些服务组合中失效
• 限流器在真实负载模式下表现不同
• 事件驱动的流程悄然丢弃消息
• 单独运行正常的事务在链式调用时出错
• 缓存失效未在服务边界之间传播

单元测试看不到这些，契约测试也看不到。而端到端测试呢？它们通过 UI 触及整个系统，层次太浅、速度太慢，且往往在最关键的集成点上使用了模拟。

这正是集成 API 测试应当发挥作用的地方。

为什么要使用集中式测试仓库？

这里提出的解决方案是 central‑testing‑repository：一个专门用于集成测试的单一仓库，用来验证部署后跨服务的行为。

收益

• 现在就提供系统级信心，而不是在多年迁移完成后才获得。
• 为跨服务故障提供组织层面的负责人（例如 QA 或平台团队）。
• 记录系统应如何交互；失败的测试能精准定位出问题的服务。

权衡

• 测试与服务代码分离维护。
• 需要团队之间的协作。
• 在服务与测试之间引入一定耦合。

尽管有这些成本，该方法仍符合混合单体‑微服务架构、多技术栈以及分布式所有权的实际情况。

对 Monorepo 的洞见

central‑testing‑repository 本质上是一个轻量级的 monorepo，只用于集成测试。

• 已经全面采用 monorepo 的公司（如 Google、Meta 等）几乎免费获得跨服务测试：所有服务都在同一位置，编写跨多个服务的测试仅仅是…写一个测试而已。
• 大多数公司因组织和工具成本无法迁移到完整的 monorepo。

central‑testing‑repository 在不需要完整迁移的情况下，提供了 monorepo 的测试优势：

• 单一仓库，可查看所有服务的 API。
• 测试针对真实部署的服务运行。
• 拥有连接分布式系统的“胶水”。

是的，这意味着当你修改 API 时需要两个 PR（一个在服务中，一个在测试中）。正是在这种协作的时刻捕获破坏性变更——在它们进入生产之前。

等等，契约测试不是能捕获这些吗？

契约测试和集成测试解决的是不同的问题。

• 契约测试验证结构： 服务能相互通信吗？是否有名为 price 的字段？它是数字吗？响应的模式是否匹配消费者的期望？
• 集成测试验证行为： 服务是否能够正确协同工作？数值 19.99 是否在多次转换中保持不变？购物车与发票之间的税费计算是否一致？副作用（库存预留、邮件发送）是否真的发生？

实际生产中漏掉的故障

这些缺陷进入生产是因为测试套件中没有针对它们的检查。

示例 1：税费计算不一致

• 购物车服务 使用 Decimal 类型：税费 = €3.80
• 发票服务 使用 float：税费 = €3.79
• 3 件商品时：购物车显示 €11.40，发票显示 €11.39

契约测试： 两者均返回 {tax: number} → 通过。
集成测试： 验证所有服务返回相同的税额 → 失败。

示例 2：日期格式解释

• 订单服务（Java） 序列化为 "01/02/2024"（美国格式 1 月 2 日）
• 发货服务（Go） 解析为 2 月 1 日（欧盟格式）

契约测试： 两者均处理 { "orderDate": "string" } → 通过。
集成测试： 创建订单，验证发货服务解析了正确的日期 → 失败。

示例 3：状态字符串大小写

• 支付服务（C#） 返回：status: "COMPLETED"
• 通知服务（Node.js） 期望："completed"

契约测试： 两者均处理 `{ “status”: “string” }