unity-tdd

测试驱动开发

TDD 是红色 → 绿色循环。这项技能是参考指南，能让这个循环产出值得保留的测试：什么是好测试、测试放在哪里、反模式，以及循环规则。每个部分都适用于每个周期：在循环前和循环中查阅，而不是事后再看。

探索代码库时，如果存在 GLOSSARY.md，请阅读它，确保测试名称和接口词汇符合项目的领域语言，并遵守你正在处理区域的 ADR。

什么是好测试

测试通过公共接口验证行为，而非实现细节。代码可以彻底改变，测试不应如此。好测试读起来像一份规范：“玩家死亡后会在上一个检查点重生”准确说明了存在什么能力，而且不会受重构影响，因为它不关心内部结构。

示例请参阅 tests.md，模拟指南请参阅 mocking.md。

接缝：测试放在哪里

接缝是你进行测试的公共边界：你可以在不深入内部的情况下观察行为的接口。测试应位于接缝处，绝不针对内部实现。

只在事先约定的接缝处测试。 编写任何测试之前，先列出要测试的接缝，并与用户确认。未经确认的接缝不得编写测试。你无法测试所有内容，因此提前约定接缝，才能让测试工作聚焦于关键路径和复杂逻辑，而不是每个边缘情况。

询问：“公共接口是什么？我们应该测试哪些接缝？” 为每个提议的接缝写一句说明，指出它能发现什么问题、无法发现什么问题。

如果接口的形态本身尚未确定（模块的深度、接缝的位置、接口应暴露什么），请使用“codebase-design”调用 Skill 工具，了解相关术语。它是关于模块、接口、深度、接缝、适配器、杠杆效应和局部性的共享术语来源，也是一份供查阅的参考，而不是要运行的会话。

反模式

• 与实现耦合：模拟内部协作者、测试私有方法，或通过旁路验证（例如查询数据库，而不使用接口）。判断信号：重构时测试会失败，但行为并未改变。
• 同义反复：断言以与代码相同的方式重新计算预期值（expect(add(a, b)).toBe(a + b)、以相同方式手工推导的快照、断言常量等于自身），因此测试必然通过，永远不可能与代码结果不一致。预期值必须来自独立的真实依据：已知正确的字面值、完整示例或规范。
• 横向切片：先写完所有测试，再写完所有实现。批量测试验证的是_想象中的_行为：测试的是事物的_形式_，而非面向用户的行为；面对真实变更时，测试会失去敏感性；而且你会在理解实现之前就确定测试结构。应改为采用纵向切片：一个测试 → 一个实现 → 重复进行，每个测试都是一发曳光弹，根据上一个周期的经验作出调整。

循环规则

• 先红后绿。 先编写失败的测试，然后只添加足以让它通过的代码。不要预想未来的测试，也不要添加推测性的功能。
• 一次一个切片。 每个周期包含一个接缝、一个测试和一个最小化实现。
• 重构不属于循环的一部分。 重构属于评审阶段（请参阅 code-review 技能），而不是红色 → 绿色的实现周期。