[!info] related notes

• 所属 MOC: Testing MOC
• 相关概念: Monorepo 测试架构, 契约测试与 CDC, Agent 测试与评估

Monorepo 测试中的共享质量资产

一句话定义

在同时包含前端、BFF、微服务和 agent 的 monorepo 里，真正决定测试体系是否工程化的，往往不是测试框架本身，而是共享质量资产是否被统一组织和版本化。

三类最关键的共享资产

packages/contracts

这里承载：

• OpenAPI / JSON Schema / AsyncAPI / Pact
• DTO 和消息边界
• 服务间共享协议

它决定的是“系统边界是否清晰”。

packages/testkit

这里承载：

• fixture
• fake
• factory
• sandbox helper
• 通用测试环境脚手架

它决定的是“测试能否低成本复用，而不是每个项目都重造一套”。

packages/evals

这里承载：

• agent 数据集
• graders
• 阈值
• 基线结果

它决定的是“agent 质量能否被持续比较和回归”。

为什么它们必须是一等公民

如果这些内容只是散落在各项目目录里的辅助文件，很快会出现：

• 协议版本不一致
• fixture 各写各的，难以复用
• eval 数据集不透明，无法做版本比较
• CI 无法基于共享资产变更触发正确测试

而一旦把它们提升成仓库级共享层，测试体系才有机会真正协同。

它们和代码本身的关系

这些资产不是测试附件，而是质量基础设施：

• contract 让边界明确
• testkit 让测试可复用
• evals 让 agent 行为可比较

它们和业务代码一样，都应该被版本化、评审和纳入 CI。

最短记忆方式

没有共享质量资产，monorepo 里的测试只会看起来集中，实际依然是碎的。