上一篇文章，我们为 task-api 确定了接口契约和统一错误结构。 今天给这个项目补测试，但重点不是让 AI 凑出更多测试文件，而是让它回答一个更重要的问题： 哪些场景最可能让这组 API 出错？ 本篇使用 Vitest + Supertest ，测试对象是 Express 应用本身，不启动真实端口。流程如下： 一、先让 AI 设计场景，不要直接生成代码 我们已经确定了任务 API 的基本规则： title 必须是非空字符串。 PATCH 只允许修改 completed 。 任务不存在返回 404 和 TASK_NOT_FOUND 。 可以发现需求中还没有定义的行为。 可以避免 AI 只测试正常请求和 null 参数。 如果测试只断言响应状态码，不检查数据是否真的改变，删除接口即使什么都没删也可能通过测试。 如果测试共用一份内存数据，前一个测试创建的任务可能影响后一个测试，测试结果就不可信。 场景确认后，再让 AI 写代码： 这里的"不要修改业务代码来迁就测试"很重要。 测试失败时，先判断是测试假设错了，还是业务代码真的有问题。不能为了让测试变绿，就把断言改成一个没有意义的宽松判断。 以"PATCH 不能修改 id "为例： 如果原代码直接把请求体合并到任务对象： 这个测试就可能失败，并暴露出一个隐藏 Bug：客户端可以覆盖服务端生成的 id 。 正确做法是只读取允许修改的字段： 测试的价值就在这里：它不是重复实现代码，而是证明一个重要边界没有被破坏。 五、再补一个经常被忽略的删除测试

删除接口不能只断言 204 ： 如果项目当前没有 GET /api/tasks/:id ，可以改为查询列表，再确认返回数组中不包含该任务。 测试应该适配已经确认的接口契约，不能为了示例偷偷增加接口。 六、如何判断 AI 生成的测试有没有价值 我会用下面 5 个问题审查测试： 还要警惕这几种"看起来很努力"的测试： 只测试永远不会失败的固定输入。 大量 Mock，却没有验证真实数据是否改变。 为了覆盖率，给每一行代码机械地写测试。 测试数量多，不等于风险覆盖得好。 在 package.json 中配置： 建议把失败结果记录成问题，而不是直接删掉失败用例： 这份记录也可以交给 AI，让它继续分析修复是否完整。 用 AI 设计测试用例，推荐遵循下面的顺序： 测试应该验证业务风险，而不是单纯追求覆盖率。 正常流程、参数边界、资源不存在和数据副作用都要考虑。 一个好的测试，应该能够发现真实 Bug。 测试失败是反馈，不要为了变绿而削弱断言。 下一篇文章，我们将完成这个小项目的最后一轮工程检查： 《小项目实战 4：代码审查、重构与提交前检查》 ✍坚持原创，求关注，点赞，收藏