TypeScript AI 全栈项目里单元测试为什么会影响服务端接口测试
我在项目中已经为核心逻辑补了单元测试，但跑服务端接口测试时，偶尔会出现通过率波动、接口响应不一致，甚至某些测试在本地能过、在 CI 上却失败。这种情况通常是哪些环节被单元测试间接影响了？
单元测试可能通过共享依赖、Mock 方式和执行环境影响接口测试
单元测试本身不会直接修改接口测试，但它可能通过几种方式间接影响服务端接口测试。常见原因包括：测试共用了同一套数据库、缓存、文件系统或全局变量；单元测试中的 Mock 覆盖了真实实现，且没有在测试结束后恢复；测试数据清理不完整，导致接口测试读到脏数据；并发执行时多个测试互相抢占资源。对于 TypeScript AI 全栈项目，若服务端接口依赖数据库、模型服务、消息队列或外部 API，这种影响会更明显。要降低干扰，可以让单元测试与接口测试隔离环境、为每类测试准备独立数据集，并确保每个测试用例结束后恢复所有被替换的依赖。
我在单元测试中把数据库、LLM 调用、第三方接口都 Mock 掉了，测试速度很快。但我担心这样会不会让后面的服务端接口测试无法真实反映业务逻辑，尤其是在 AI 相关链路里，这种风险大不大？
过度 Mock 会让单元测试和接口测试覆盖的目标偏离
过度 Mock 的确会让单元测试只验证“函数调用是否正确”，却无法验证“真实链路是否可用”。在 TypeScript AI 全栈项目中，服务端接口往往依赖请求校验、业务服务、数据库事务、向量检索、模型调用和结果转换。如果单元测试把这些关键环节都替换成 Mock，就可能掩盖接口层的集成问题，比如参数格式变化、字段映射错误、超时处理缺失、异常分支未覆盖。接口测试的价值就在于验证真实服务链路，因此它更适合补足单元测试的盲区。更稳妥的做法是：单元测试保留少量关键依赖 Mock，用于验证纯逻辑；接口测试尽量使用真实依赖或接近真实的测试环境，确保链路行为与线上一致。
我的单元测试主要覆盖业务函数，运行很快也都通过了，但服务端接口测试经常出现超时、响应格式错误或状态码不一致。明明核心逻辑已经测过了，为什么接口层还是会出问题？
单元测试只验证局部逻辑，接口测试还会暴露链路和运行时问题
单元测试通常只关注单个函数或类的输入输出，不会完整覆盖 HTTP 层、序列化、异步调度、网络延迟、并发冲突和资源耗尽等问题。TypeScript AI 全栈项目里，服务端接口测试需要经过路由、控制器、服务层、数据访问层，以及可能存在的模型推理或外部服务调用，这些环节任何一个出现性能瓶颈或异常处理不完善，都可能导致接口测试失败。比如 LLM 请求超时、数据库连接池不足、JSON 结构变化、请求体校验错误、错误被吞掉后返回了空响应，都属于单元测试不容易直接发现的问题。接口测试的作用就是把这些真实运行时问题暴露出来，因此即使单元测试全部通过，也不能替代接口测试。