API Mock 夹具生成与审阅

目标与适用范围

生成可重复的 Mock 负载，构造符合格式的边界值，发现易混淆字段名，并在共享临时 Mock 服务前完成复核。
本指南将当前任务范围转化为可复核的交付结果。请保留源文件、中间产物和关键判断，让后续协作者能够理解检查了什么以及为什么这样处理。

准备证据并作出选择

• 准备请求和响应结构、必填字段、枚举值，以及一小组有效和无效场景。

• 只使用虚构值；在输入夹具前移除真实凭据、访问令牌、客户记录和其他个人数据。

• 明确目标测试环境、Mock 有效期、夹具负责人，以及需要保留的验收证据。

• 决策点: 字段应使用数据配置生成，还是使用严格模式生成？. 结构化记录和可重复的字段组合使用 Test Data Faker Builder；标识符、邮政编码或版本字符串等必须满足明确模式的值，则使用 Regex to String Generator，并在记录中保留模式和样例依据。

• 决策点: 夹具是否已经可以暴露为 Mock 接口？. 不要在生成后立即发布。先解决命名冲突，检查边界值，删除看起来敏感的内容，并确认 Mock 定义只指向隔离的非生产环境。

按步骤完成工作流

1. 构建结构化夹具

在 Test Data Faker Builder 中配置记录结构、必填字段、受控分类和可重复的样例数量。把正常响应、空结果和故意触发校验失败的样例分开，不要混进同一个负载。 使用 test-data-faker-builder.

2. 填充严格格式的值

对于标识符等受约束字符串，根据已经审阅的正则表达式生成样例。既检查匹配值，也准备接近但不匹配的值，让夹具覆盖格式边界，同时不要把正则通过误认为业务有效。 使用 regex-to-string-generator.

3. 审阅字段名与冲突风险

把组合后的 JSON 或 schema 交给命名冲突检测器。及早改掉视觉相近的字段、含义不明的缩写和相互竞争的前缀，避免客户端代码或文档依赖错误命名。 使用 mock-data-naming-conflict-detector.

4. 安全地暴露已审阅的 Mock

前面检查通过后再创建临时 Mock 定义。核对接口路径、方法、响应模板、过期时间和访问假设；只使用虚构数据，并记录这个 Mock 不会测试真实服务的行为、延迟、授权或持久化。 使用 api-mock-server.

交付前验收结果

• 夹具包含必填字段和可重复的代表性值，并明确区分有效响应、空结果和故意失败场景。
• 受格式约束的值符合声明模式；命名审阅没有未解决的易混淆字段名或前缀冲突。
• Mock 定义只在预期的临时非生产范围内暴露虚构且非敏感的数据；审阅记录明确说明它不能代替真实服务的契约或集成测试。

常见问题

• 这套工作流能测试真实 API 吗？ 不能。它负责准备并暴露临时 Mock 夹具。真实服务的行为、认证、持久化、延迟和集成兼容性仍需单独做契约或集成测试，可继续使用相关的 API 契约测试工作流。
• 什么数据可以放入夹具？ 使用虚构的姓名、标识符、地址、令牌和账户状态。不要把生产凭据、访问令牌、客户导出数据或其他个人信息粘贴到夹具或 Mock 定义中。
• 为什么正则既要生成匹配值，也要生成近似失败值？ 匹配值展示客户端预期的形状，近似失败值则检验拒绝逻辑和边界处理。正则匹配只能说明语法符合，不能证明值唯一、已授权或具有业务含义。
• 什么时候可以共享夹具？ 只有在记录并接受必填字段、边界场景、命名检查、敏感数据复核、Mock 配置和非生产范围后，才应共享给团队。