用途
TDD 技能用于指导测试驱动开发中的红 → 绿循环，目标是在该循环中产出值得长期保留的测试。它覆盖四个方面的内容：什么是好测试、测试应放在哪里、“接缝”（seam）如何约定、以及循环本身的规则。资料强调，每个部分都应在每个循环周期中前后参照，而不是在循环结束后才补看。
什么是好测试
- 测试应通过公共接口验证行为，而不是验证实现细节；代码可以整体重写，测试不应随之失效。
- 好测试读起来像规格说明，例如“user can checkout with valid cart”能直接说明存在什么能力；它不关心内部结构，因此能经受重构。
接缝：测试放在哪里
- 接缝是可测试的公共边界，即在不深入内部的情况下观察行为的接口。测试只放在接缝处，绝不针对内部实现。
- 只在事先约定好的接缝处写测试；不得在未确认的接缝上写测试。无法测试所有内容，因此提前约定接缝能让测试精力集中在关键路径和复杂逻辑上，而不是每个边缘情况。
- 接缝可能已经约定，应按以下来源顺序取用：工单中的 Seams 行（或远程工单中的 Seams 段）；规格中的 Testing Decisions；若都没有则为空。
- 来自上述来源的接缝视为已确认，可直接在其上写测试而无需再问；只对不在列表中的接缝询问用户，并在一经同意后加入列表。
- 若没有来源（独立使用、无工单或规格），应写下要测试的接缝，并在写任何测试前与用户确认。可询问：“公共接口是什么，我们应该测试哪些接缝？”并为每个提议的接缝附一行说明：它能捕获什么、遗漏什么。
- 若接口形态本身存疑（模块有多深、接缝应放在哪里、接口应暴露什么），应先解决这些问题，再约定接缝。
反模式
- 实现耦合：模拟内部协作者、测试私有方法，或通过旁路验证（例如查数据库而不是走接口）。识别信号是：重构后行为未变但测试失败。
- 同义反复：断言按代码相同的方式重新计算期望值（如 expect(add(a, b)).toBe(a + b)、手工按同样方式推导的快照、常量与自身比较），因此按构造必然通过，永远无法与代码产生分歧。期望值必须来自独立可信来源：已知正确字面量、已演算示例、规格说明。
- 横向切片：先写完全部测试再写全部实现。批量测试验证的是想象行为：测试的是事物的形状而非用户可见行为，测试对真实变化变得不敏感，并在理解实现之前就锁定测试结构。应改用纵向切片：一个测试 → 一次实现 → 重复，每个测试都是回应上一轮所学的“曳光弹”。
循环规则
- 红先于绿：先写失败的测试，然后只写足够让它通过的代码；不要预判未来测试或添加投机性功能。
- 一次一个切片：每个周期一个接缝、一个测试、一次最小实现。
- 重构不属于该循环：重构属于实现技能中的重构步骤，而不是红 → 绿实现循环。
探索代码库时的要求
- 阅读 GLOSSARY.md（若存在），使测试名称和接口词汇与项目领域语言一致。
- 尊重所触及区域的 ADR（架构决策记录）。
适用场景与限制
适用于用户希望以测试先行方式构建功能或修复缺陷、提到 red-green-refactor，或需要集成测试的场景。资料未提供具体平台、收费、价格或效果信息；该技能本身是一份规范参考，不包含可执行代码或安装命令。