test-driven-developmentlisted

## 是什么 帮你把"先写实现再补测试"的常见反模式倒过来，让每一个新功能或修复都先有一条会失败的测试作为契约，确保实现真的解决了那个具体需求，而不是绕过了它。 ## 怎么用 1. 接到需求或 bug 报告时，先让本技能把目标转成一条最小可观察的测试用例：输入是什么、期望输出是什么。 2. 运行测试，亲眼看到它失败（红灯），确认测试确实在检查目标行为，而不是一开始就被意外满足。 3. 写最小实现让测试通过（绿灯），不在此阶段做任何额外优化或扩展。 4. 在绿灯保护下，让本技能引导一轮重构（橙灯到绿灯之间），优化结构而不改外部行为。 5. 把所有新增测试纳入持续集成流水线（CI（持续集成）），让后续每次提交都自动跑一遍，避免回归悄悄溜进主分支。 ## 架构图 ```mermaid flowchart LR A[需求或 bug] --> B[写失败测试 红灯] B --> C[最小实现 绿灯] C --> D[重构优化] D --> E[纳入 CI 流水线] E --> F[防止回归] ``` # Test-Driven Development (TDD) ## Overview Write the test first. Watch it fail. Write minimal code to pass. **Core principle:** If you didn't watch the test fail, you don't know if it tests the right thing. **Violating the letter of the rules is violating the spirit of the rules.** ## When to Use **Always:** - New features - Bug fixes - Refactoring - Behavior changes **Exceptions (ask your human partner):** - Throwaway prototypes - Generated code - Configuration files Thinking "skip TDD just this once"? Stop. That's rationalization. ## The Iron Law ``` NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST ``` Write code before the test? Delete it. Start over. **No exceptions:** - Don't keep it as "reference" - Don't "adapt" it while writing tests - Don't look at it - Delete means delete Implement fresh from tests. Period. ## Red-Green-Refactor ```dot digraph tdd_cycle { rankdir=LR; red [label="RED\nWrite failing test", shape=box, style=filled, fillcolor="#ffcccc"]; verify_red [label="Verify fail