该技能是一个强制测试驱动开发（TDD）的规则集合，适用于任何需要生成或修改代码的开发场景。其核心原则是：“如果你没有亲眼看到测试失败，你就不知道它是否在测试正确的东西。”
【用途与激活时机】 在以下情况启用：实现任何新功能、修复 Bug（先写复现 Bug 的测试，再修复）、重构（修改前后测试都必须通过）、扩展 API、以及为每个导出函数编写代码时。技能会阻止无测试的代码生成。
【Red-Green-Refactor 循环】
- RED：先写一个会失败的测试。测试必须因正确的原因失败（如函数不存在或返回错误结果），而不是因为测试自身的语法错误。
- GREEN：编写最简单、最小化的代码让测试通过，不做优化、不加额外功能、不做“显而易见”的扩展。
- REFACTOR：在多个测试通过后进行重构，重构时所有现有测试必须保持通过，不得添加新行为，只改进代码结构，每步重构后都要运行测试。
【13 条无效借口】 技能列出并反驳了 13 种常见借口，例如“太简单不用测”“以后再测”“已经手动测过”“赶时间没空写测试”“私有方法不用测”“UI 代码没法测”“逻辑太简单”“我们有 QA 流程”“代码只是临时的”“测试拖慢开发”“遗留代码没测试”“框架/库会自己测”“Mock 太麻烦”。每条都给出实际理由，强调测试的可复现性、长期加速效应与设计改善。
【验证清单】 每次提交前必须满足：每个导出函数至少有一个测试；每个测试在实现前都曾失败（观察到 RED）；每个测试只验证一件事（单一断言原则）；每个测试对应最小代码（避免过度设计）；覆盖边界情况（null/undefined 输入、空数组/字符串、边界值如 0、MAX_INT、负数、错误输入如期望 TypeError）；测试名称描述行为（should [期望结果] when [条件]）；提交中不得包含 skip 或 only 测试；新代码覆盖率至少 80%。
【实践工作流】
- 创建测试文件；2. 编写最小失败测试；3. 运行测试确认失败（例如 npm run test -- --run 文件路径）；4. 编写最小实现；5. 运行测试确认通过；6. 为边界情况编写下一个测试，回到步骤 3 循环。
【反模式】 禁止先写代码后补测试；禁止一次实现过多代码；禁止为了让测试通过而修改测试（应修正实现或澄清需求）。
【框架示例】 提供 React 组件（Vitest + Testing Library）、API 端点（Supertest）、异步代码（mock 重试）等测试模式示例。
【违规处理】 一旦违反 TDD，技能会停止进一步代码生成，发出警告“检测到 TDD 违规：[描述]”，展示正确的 TDD 流程，并询问“我应该先写测试吗？”
【成功度量】 测试与代码之比至少 1:1；新代码覆盖率至少 80%；Red-Green 周期短（每个功能 5–10 分钟）；单元测试执行时间少于 10 秒。
【命令】 运行单个测试（验证 RED）、运行所有测试（提交前）、覆盖率报告、监听模式（开发中）。
【与其他技能集成】 与 code-quality-gate（TDD 测试属于 Gate 1 预提交）、strict-typescript-mode（测试也需类型安全）、supervisor（检查代理验证 TDD 遵守情况）集成。
【来源与延伸阅读】 Kent Beck《Test-Driven Development: By Example》、Robert C. Martin《Clean Code》第 9 章、Martin Fowler《Refactoring》（重构时的测试安全）。