TypeScript AI 服务端实现服务端接口测试时单元测试该怎么封装
在做 TypeScript 的 AI 服务端开发时，我想把接口测试和单元测试分开管理，避免测试代码互相耦合。应该按什么思路来封装，才能让后续维护更轻松？
按测试层级拆分，统一公共能力封装
可以按“单元测试”和“接口测试”两层来设计。单元测试只关注函数、类、服务方法的行为，重点是隔离外部依赖，常见做法是把数据库、HTTP 请求、AI 模型调用都 mock 掉。接口测试则更接近真实请求流程，关注路由、参数校验、鉴权、返回结构和错误处理。
封装时建议抽出公共测试工具层，比如：请求客户端封装、测试数据工厂、mock 工具、断言工具、环境初始化脚本。这样每个测试文件只需要关注业务场景，不用重复写初始化和清理逻辑。对于 AI 服务，还可以把模型调用封装成独立 provider，测试时用假实现替代真实调用，提升稳定性和执行速度。
我在测试 AI 服务端接口时，经常纠结哪些部分应该模拟，哪些部分应该直接连真实服务。为了保证测试既稳定又有价值，通常怎么划分更合理？
核心业务用 mock，链路验证保留少量真实测试
一般来说，单元测试里适合 mock 掉外部依赖，包括数据库、缓存、第三方 AI 平台、消息队列、文件存储、时间和随机数。这样可以让测试结果稳定，避免外部波动影响 CI。
需要保留少量真实环境测试的部分，通常是最关键的链路，比如接口路由是否可达、请求参数是否能正确进入业务层、AI 结果的解析逻辑是否符合预期。若成本较高，可以使用测试专用账号、测试环境模型或固定返回值的沙箱服务。这样的组合能兼顾效率和可信度。
我希望不同测试文件都能复用同一批请求参数、响应样例和错误样例，避免到处复制粘贴。测试数据和断言逻辑应该怎么设计才更清晰？
用工厂函数和 fixture 统一管理测试数据
可以把测试数据分成三类来管理：固定样例、工厂数据和动态生成数据。固定样例适合通用请求体、标准响应和常见错误；工厂数据适合按场景生成不同字段组合；动态生成数据适合涉及时间戳、ID、token 的场景。
在目录结构上，可以建立 fixtures、factories、mocks、helpers 这几类文件夹。fixtures 放静态样例，factories 负责按需生成对象，helpers 放通用断言和初始化方法。这样在测试 AI 服务接口时，每个用例只需要调用现成的数据工厂，不必重复定义结构，也更容易扩展边界场景。
我在写很多接口测试时，每个文件都要重复启动实例、准备数据、清理数据库，代码很臃肿。有没有更适合 TypeScript 项目的封装方式，能让测试代码更干净？
把环境搭建抽到统一测试基座里
可以建立一层统一的测试基座，专门负责测试环境初始化和资源清理。比如封装 beforeAll、afterAll、beforeEach、afterEach 中的通用逻辑，把服务启动、数据库连接、缓存清理、临时文件删除都集中到一个地方。
对于 TypeScript 项目，还可以把这些能力写成 test harness 或基类，供不同测试文件继承或调用。这样业务测试只保留场景描述和断言，公共流程由基座接管。若接口测试需要启动完整应用实例，也可以把 app 创建、注入依赖、关闭资源封装成一个 createTestApp 方法，提升复用率并减少维护成本。