案例 21 · 自动化单元测试轰炸机：一键为开源仓库补齐 90% 单元测试

> 📘 本案例有深度详解（含真实提示词与全程调试）：案例21 · 单元测试自建闭环

【关键工具】 Claude Code + Jest / Vitest

【70% Vibe】

这个案例真正实现了导言里 Boris Cherny 提到的"自建闭环"：AI 自动阅读项目的核心逻辑，写出测试用例，然后在本地终端反复运行、看哪个测试失败、自己修改、再运行，如此循环，直到所有测试通过。它把"写测试"这件最枯燥、又最重要的工程实践自动化了，能把一个裸奔的开源仓库的测试覆盖率快速拉到 90%。

flowchart LR
    A[AI 阅读核心逻辑] --> B[生成测试用例]
    B --> C[终端运行测试]
    C --> D{全部通过?}
    D -->|否| E[定位失败原因<br/>自动修改]
    E --> C
    D -->|是| F[覆盖率达标]
    style F fill:#e5ffe9,stroke:#3a3

【30% Engineering】

能"自动写测试"不稀奇，能"写出有意义的测试"才是 30%。

第一是外部依赖的 Mock 编写。真实代码会调用数据库、第三方 API、文件系统。测试时不能真的去连这些外部服务（慢、不稳定、有副作用），必须用"Mock（模拟替身）"把它们假装出来。如何为复杂的外部依赖编写正确的 Mock，让测试既快又可靠，是 AI 最容易出错、最需要人把关的地方。

第二，也是更隐蔽的——防止 AI 为了"凑覆盖率"而写无效测试。覆盖率是一个很容易被"作弊"的指标。AI 为了达到 90%，可能写出一堆"运行了代码但什么都没断言"的空测试，甚至写出能跑通却毫无意义的死循环测试。覆盖率上去了，质量却是假的。识别并杜绝这种"自欺欺人的测试"，需要人去审视"这个测试到底验证了什么"。