3. 集成测试基础：定义、目标与微服务角色

在缓存一致性治理体系中，集成测试是连接单元验证与端到端验证的关键桥梁。它不关注单个函数的正确性，而是聚焦于模块之间、服务之间、以及系统与外部存储（如 Redis、数据库）之间的协作契约是否被正确履行。对于缓存一致性问题，集成测试是发现“缓存与数据库数据不一致”、“缓存失效策略未生效”、“分布式锁未正确释放”等跨组件缺陷的最早防线。

3.1 集成测试的定义与目标

定义：集成测试（Integration Testing）是在单元测试之后，将已通过单元测试的模块、服务或组件按照系统设计进行组装，验证它们之间的接口、数据传递、交互协议以及对外部依赖（如缓存中间件、消息队列、数据库）的调用是否符合预期。

核心目标：

• 接口契约验证：确保服务 A 调用服务 B 的 API 时，请求参数格式、响应结构、异常码定义与双方约定的契约一致。
• 数据一致性校验：验证跨组件的数据流转是否完整、准确，特别是缓存与数据库之间的双写一致性、缓存穿透/击穿/雪崩防护逻辑是否生效。
• 外部依赖集成：确认系统与 Redis、MySQL、Kafka 等中间件的连接、认证、读写操作在真实或模拟环境下正常。
• 安全权限验证：在集成层面检查服务间调用的鉴权 Token 传递、缓存操作的 ACL 权限、敏感数据的脱敏策略是否被正确执行。

3.2 集成测试与单元测试的区别

理解集成测试与单元测试的差异，有助于合理分配测试资源，避免在缓存一致性治理中出现“测试盲区”或“过度测试”。下表从多个维度进行对比：

3.3 集成测试在微服务架构中的角色

在微服务架构中，每个服务独立部署、独立演进，服务间通过轻量级通信协议（HTTP/REST、gRPC、消息队列）协作。集成测试在这一架构中承担着以下不可替代的角色：

1. 服务间契约守护者：微服务团队通常由不同小组维护，集成测试作为“活的契约文档”，确保服务 A 的接口变更不会破坏服务 B 的调用预期。对于缓存一致性，这意味着缓存服务（如 Redis Cluster）的 API 变更不会导致业务服务缓存读写失败。
2. 数据一致性验证者：在分布式缓存场景中，一个业务操作可能涉及“订单服务写缓存→库存服务读缓存→支付服务更新数据库”。集成测试能够模拟这一完整调用链，验证缓存数据在跨服务流转后是否仍与数据库保持一致。
3. 安全权限策略执行者：微服务架构中，缓存中间件通常配置有访问控制列表（ACL）或命名空间隔离。集成测试可以验证：服务 A 是否无法越权访问服务 B 的缓存键空间？缓存操作的鉴权 Token 是否在服务间正确传递？
4. 故障隔离与恢复验证者：集成测试可以模拟缓存服务宕机、网络分区、超时等故障场景，验证业务服务是否能够降级（如直接查询数据库）、熔断（如 Hystrix 熔断器打开）并最终恢复。

3.4 集成测试在缓存一致性治理中的典型实践

在微服务缓存一致性治理中，集成测试通常围绕以下三个层次展开：

• 层一：单服务内部集成测试——验证业务服务与本地 Redis 实例的交互，包括缓存读写、过期策略、序列化/反序列化。使用 Testcontainers 启动嵌入式 Redis 容器，避免依赖外部环境。
• 层二：服务间集成测试——通过 WireMock 或 MockServer 模拟下游服务的缓存读写接口，验证本服务在缓存命中/未命中、缓存超时等情况下的行为是否符合预期。
• 层三：安全权限集成测试——验证缓存中间件的 ACL 配置是否生效，例如：使用只读 Token 的服务尝试写缓存时是否被拒绝；服务间调用时鉴权 Header 是否被正确透传至缓存操作。