tdd

用途

TDD（Test-Driven Development）是一个测试驱动开发技能，核心是“红 → 绿”循环。该技能作为参考规范，目标是让这个循环产出真正值得保留的测试：说明什么是好测试、测试应该放在哪里、有哪些反模式，以及循环本身的规则。技能强调，每一节内容都适用于每一个循环周期，应当在循环之前和进行中查阅，而不是在循环结束后才看。

适用场景包括：用户希望以测试先行的方式构建功能或修复缺陷、提到“red-green-refactor”（红-绿-重构），或希望编写集成测试。

主要能力

什么是一个好测试

测试通过公共接口验证行为，而不是验证实现细节。代码可以完全重写，测试不应该需要跟着改。一个好的测试读起来像一份规格说明：例如“user can checkout with valid cart”能准确说明存在什么能力，并且由于它不关心内部结构，因此能在重构后依然存活。相关资料指向 tests.md（测试示例）和 mocking.md（mock 使用指南）。

接缝（Seam）：测试应该放在哪里

接缝是指你进行测试的公共边界：在这个接口上你可以观察行为而无需深入内部。测试应当位于接缝处，绝不应针对内部实现编写。

只能在事先商定的接缝上编写测试。在编写任何测试之前，先写下待测试的接缝并与用户确认。没有确认的接缝不写测试。你不可能测试一切，因此提前商定接缝，可以让测试投入落在关键路径和复杂逻辑上，而不是浪费在每个边缘情况上。

需要询问：“公共接口是什么，我们应该测试哪些接缝？”对每个提议的接缝，用一句话说明它能捕获什么、会漏掉什么。

当接口本身的形态存在疑问时（例如模块应该有多深、接缝应该放在哪里、接口应该暴露什么），可以通过 Skill 工具调用“codebase-design”来获取统一词汇。该技能是模块、接口、深度、接缝、适配器、杠杆和局部性等术语的共同来源，并且是一份可供查阅的参考，而不是一个需要运行的会话。

反模式

• 实现耦合（Implementation-coupled）：mock 内部协作者、测试私有方法，或通过侧信道验证（例如查询数据库而不是使用接口）。判断标志是：重构时测试失败，但行为并没有改变。
• 同义反复（Tautological）：断言以与代码相同的方式重新计算期望值（如 expect(add(a, b)).toBe(a + b)，手工按同样方式推导的快照，把常量断言为它自身），因此它按构造就会通过，永远不可能与代码产生分歧。期望值必须来自独立的事实来源：已知正确的字面量、已算好的示例，或规格说明。
• 横向切片（Horizontal slicing）：先写完所有测试，再写所有实现。批量测试验证的是想象出来的行为：你测试的是事物的形状而不是面向用户的行为，测试对真实变化变得不敏感，并且在理解实现之前就锁定了测试结构。应当改用纵向切片：一个测试 → 一个实现 → 重复，每个测试都是一颗曳光弹，响应上一个循环教给你的东西。

循环规则

• 红色先于绿色。先写失败的测试，然后只写足够让其通过的代码。不要预判未来的测试，也不要添加投机性的功能。
• 一次一个切片。每个循环一个接缝、一个测试、一个最小实现。
• 重构不属于循环的一部分。重构属于评审阶段（参见 code-review 技能），而不是红 → 绿实现循环。

使用方式

在探索代码库时，读取 GLOSSARY.md（如果存在），使测试名称和接口词汇与项目的领域语言保持一致，并尊重你正在改动的区域中的 ADR。在编写任何测试前，先写出待测试的接缝并与用户确认；随后按“一个测试 → 一个实现”的纵向切片方式推进循环。当接口形态本身存疑时，可查阅 codebase-design 技能获取术语参考。

适用场景

• 希望以测试先行的方式构建功能或修复缺陷。
• 需要编写集成测试。
• 提到“red-green-refactor”开发流程。

限制

关于收费、价格、平台支持等事实，资料中暂未提供。技能资料主要描述方法论、规则与反模式，未提供具体安装命令或代码示例。