测试驱动开发

为什么要先写测试？

面对代码库时，最大的风险往往不是“代码写不出来”，而是“不知道改坏了哪里”。没有测试的项目对 AI Agent 来说是个沉重的包袱：任何一次重构或修 Bug 都只能靠肉眼观察输出结果，“看起来是对的” 往往掩盖了潜在的破坏性变更。缺乏测试不仅让验证成本飙升，还会让代码质量退化。

本技能将测试视为唯一的证据标准：“看起来没问题” 等于 没做完。

核心工作流：适应性 TDD

TDD 的循环是通用的，但命令不是。本技能的执行逻辑如下：

• 发现技术栈：在编写第一个测试前，必须识别当前仓库的构建系统和测试配置。

寻找 package.json、pyproject.toml、Makefile 等配置文件。
优先使用仓库内置的包装器（如 ./gradlew、./mvnw），而不是全局安装的工具。

• 执行 RED-GREEN-Refactor 循环：

RED：先写一个失败的测试。
GREEN：编写最少的代码让测试通过。

• 证明式修复：针对 bug 修复，采用 Prove-It 模式，先写一个复现 bug 的测试，再进行修复。
• 验证标准：循环中运行聚焦测试命令，完成前运行全量测试命令。

适用边界与注意事项

• 必须使用的场景：实现任何新逻辑、修改现有功能、增加边界处理，以及任何可能破坏现有行为的变更。
• 何时不使用：纯配置更改（如 .env 配置）、文档更新或静态内容变更。这些无行为影响的改动不需要 TDD。
• 浏览器测试：对于涉及前端行为的改动，建议结合 Chrome DevTools MCP 进行运行时验证，而不仅限于代码逻辑层。