tdd

用途：该技能用于在构建功能或修复缺陷时执行测试驱动开发（TDD），采用红-绿-重构（red-green-refactor）循环，并强调测试应通过公共接口验证行为，而非耦合实现细节。\n\n主要能力与理念：核心原则是测试验证行为而非实现细节，代码可以大幅变化而测试不必跟着改。好的测试是集成风格，经过公共 API 执行真实代码路径，读起来像规格说明（例如"用户可以用有效购物车结账"），并能经受重构。坏的测试耦合内部实现、mock 内部协作者、测试私有方法或通过外部手段验证；若重命名内部函数就导致测试失败，说明测试的是实现而非行为。资料提及可参考 tests.md 获取示例、mocking.md 获取 mock 指南。\n\n反模式：禁止水平切片，即先写全部测试再写全部实现。这会产生批量测试、测试想象行为、只测数据结构和函数签名、对真实变化不敏感、在未理解实现前锁定测试结构等问题。正确做法是通过曳光弹进行垂直切片：一个测试对应一个实现，循环推进。\n\n使用方式（工作流）：1）规划：写代码前与用户确认接口变更与要测试的行为（按优先级），使用 codebase-design 及其深化指引命名 Module、Interface、Seam，在 mock 前复用已接受的设计或先就 Seam 达成一致，列出要测试的行为（非实现步骤），并获得用户批准；可询问公共接口应是什么样、哪些行为最重要。若 Seam 未定且不同答案会改变公共接口或测试边界，应设置人工确认关卡并暂停。2）曳光弹：先写一个确认系统某一行为的测试，RED 失败，GREEN 写最少代码通过。3）增量循环：对每个剩余行为，一次一个测试，只写够通过当前测试的代码，不预判未来测试，保持测试聚焦可观察行为。4）重构：全部测试通过后，将聚焦清理交给 code-simplification，再将冻结的候选交给 code-review；TDD 不拥有这两个质量阶段，也不重复其检查清单；RED 时绝不重构，先到 GREEN。\n\n每轮检查清单：测试描述行为而非实现；测试仅使用公共接口；测试能经受内部重构；代码对当前测试最小；不添加投机性功能。\n\n限制：测试无法覆盖一切，应与用户确认最关键的行为，将测试精力集中在关键路径和复杂逻辑上，而非每个边界情况。资料未提供安装命令、平台支持、收费或价格等信息。