TypeScript 开发 AI 服务端接口测试时单元测试怎么设计类型
我在写 AI 服务端接口的单元测试时，发现请求参数、返回结果、Mock 数据和断言对象的类型很多。如果类型设计不清晰，测试代码就很难维护。通常应该从哪些角度来组织测试类型，才能让用例既稳定又容易扩展？
围绕请求、响应、Mock 和断言结果拆分测试类型
可以把测试类型按职责拆开设计，而不是把所有类型都堆在一个大接口里。常见做法是为请求参数、服务返回值、Mock 依赖、错误对象分别定义独立类型，再通过联合类型或泛型组合起来。这样做的好处是，测试代码在模拟不同 AI 接口场景时更清楚，也便于后续新增模型参数、流式返回或错误分支。对于接口测试，建议尽量复用业务层已有的 DTO、Schema 或类型推导结果，避免在测试里重复定义一套类型。
AI 服务端接口经常不是简单的同步返回，还可能有流式输出、超时、重试、限流、鉴权失败等情况。单元测试里如果只写一个通用返回类型，很难覆盖这些差异。有没有更适合的类型设计方式来描述这些复杂场景？
用联合类型和状态枚举描述不同响应路径
对于这类接口，建议用状态枚举配合联合类型来表达测试场景，例如把响应分成 success、streaming、timeout、rate_limited、unauthorized 等不同状态，每种状态对应一组明确的字段。这样断言时可以根据状态直接收窄类型，减少无效字段访问。流式响应可以单独定义 chunk 类型、结束标记类型和聚合结果类型，异步场景则可以把 Promise 返回值和异常类型分开建模。这样既能提高类型安全，也能让测试用例更贴近真实接口行为。
我在测试中经常手写 Mock 数据，写着写着就和真实接口结构不一致了，导致测试通过了但代码上线后出问题。怎样设计类型，才能让 Mock 数据和真实接口保持同步，减少这种风险？
让 Mock 类型从真实业务类型派生出来
最稳妥的方式是让 Mock 类型尽量从真实类型派生，而不是独立手写。可以使用 TypeScript 的 typeof、ReturnType、Parameters、Pick、Partial、Required 等工具类型，直接从服务函数、API 响应类型或领域模型中提取测试所需结构。对于只关心部分字段的场景，可以用 Pick 或 Partial 生成轻量 Mock；对于完整响应校验，则尽量使用完整接口类型。这样当真实接口字段调整时，测试编译阶段就能及时暴露问题，避免类型漂移。