写代码先写测试？Claude 这个 Skill 把 TDD 带进了日常开发流

写代码最痛苦的时刻是什么？不是从零开始写，而是写完之后发现——跑不通，一堆边界情况没考虑，测试用例还是事后补的。

test-driven-development 这个 Skill 就是来解决这个问题的。它的核心逻辑很反直觉：先告诉 Claude 你要做什么，然后先让它生成测试用例，测试跑通了你再写实现。

听起来多了一步，实际上效率反而更高。因为测试先写，你就被迫把需求想清楚——输入是什么、输出是什么、边界 case 有哪些。没想清楚的话，测试根本写不出来。

实际跑起来是这样的流程：
1. 你描述需求和功能点
2. Claude 先写一套测试用例，覆盖正常路径和异常路径
3. 测试跑失败（因为还没写实现）
4. Claude 再根据测试写实现代码
5. 测试通过，代码完成

这样做有几个直接好处：

代码质量稳定，不会写着写着跑偏。因为测试就是你的契约，实现必须满足契约。

减少返工。很多 bug 是在补测试的时候发现的，TDD 把这个环节提前了。

边界意识变强。你会主动想：空输入怎么办、超长字符串怎么办、并发情况怎么处理——这些在写实现之前就被测试覆盖了。

适合什么场景？对代码质量要求高的项目、核心业务逻辑、需要长期维护的基础库。日常小脚本可能不需要这么重的流程，但只要是多人协作或长期维护的代码，TDD 的价值就很明显。

安装方式也很简单：

npx skills add https://github.com/ComposioHQ/awesome-claude-skills --skill test-driven-development

装完之后 Claude Code 会自动识别，每次你描述需求时它会判断是否触发这个 Skill——当然你也可以直接说「用 TDD 模式开发这个功能」。

GitHub 上还有配套的 finishing-a-development-branch 和 subagent-driven-development，三个组合起来基本覆盖了「开发→测试→收尾」的全流程。

如果你的项目经常面临「代码写完发现不符合需求」的问题，值得试试这个思路。

GitHub: https://github.com/ComposioHQ/awesome-claude-skills/tree/master/test-driven-development