测试驱动开发（TDD）是一种以红—绿循环为核心的开发方式。该技能定位为一份参考规范，帮助这一循环产出值得长期保留的测试，内容涵盖好测试的标准、测试的放置位置、常见反模式以及循环规则。技能说明这些内容应在每个循环中反复查阅，而不是等循环结束后再检查。
用途与适用场景
当用户希望以测试优先的方式构建功能或修复缺陷，提到“red-green-refactor”，或需要集成测试时，可使用该技能。它适合把测试作为规格说明来驱动实现，并把测试精力集中到关键路径和复杂逻辑上。
好测试的标准
测试应通过公共接口验证行为，而不是实现细节。代码可以完全改变，测试不应随之改变。好测试读起来像一份规格说明，例如“用户可以用有效购物车结账”能直接说明存在什么能力，并且不关心内部结构，因此能在重构后继续成立。具体示例见 tests.md，模拟（mocking）指南见 mocking.md。
接缝与测试位置
接缝（seam）是测试所在的公共边界：你在这个接口上观察行为，而不深入内部。测试只写在接缝处，绝不针对内部实现。写任何测试之前，应先写下待测试的接缝并与用户确认；未确认的接缝不写测试。无法测试一切，因此提前约定接缝，才能让测试投入落在关键路径和复杂逻辑上，而不是每个边缘情况。应询问：“公共接口是什么，我们应该测试哪些接缝？”当接口形态本身存疑时（模块深度、接缝位置、接口应暴露什么），可调用 Skill 工具查阅 codebase-design，以获取模块、接口、深度、接缝、适配器、杠杆和局部性等共享术语；它是参考，不是要运行的会话。
反模式
实现耦合：模拟内部协作者、测试私有方法，或通过旁路渠道验证（例如查数据库而不是使用接口）。识别信号是：重构后行为未变，测试却失败。同义反复：断言以与代码相同的方式重新计算期望值（如 expect(add(a, b)).toBe(a + b)、手工按同样方式推导的快照、断言常量等于自身），因此按构造就会通过，永远无法与代码产生分歧。期望值必须来自独立的事实来源：已知正确的字面量、演算示例或规格。横向切片：先写所有测试，再写所有实现。批量测试验证的是想象的行为，测的是事物的形状而非面向用户的行为，测试对真实变化不敏感，并且在理解实现之前就锁定了测试结构。应改用垂直切片：一个测试 → 一个实现 → 重复，每个测试都是一颗曳光弹，回应上一轮循环学到的内容。
循环规则
红先于绿：先写失败测试，然后只写足够让测试通过的代码，不预判未来测试，也不添加推测性功能。一次一个切片：每个循环一个接缝、一个测试、一个最小实现。重构不属于该循环，而属于审查阶段（见 code-review 技能），不属于红—绿实现循环。
其他注意事项
探索代码库时应阅读 CONTEXT.md（若存在），使测试名称和接口词汇与项目领域语言一致，并遵守所触及区域中的 ADR。