Tdd

---
name: tdd
description: "测试驱动开发纪律。触发：行为改动要 test-first，用户提到 red-green-refactor 或集成测试，或 implement 在预先商定的 seams 上驱动测试循环。"
---

# TDD（red → green）

测试验证公共接口上的行为，不验证实现细节；实现可以整个换掉，测试不该跟着换。每个循环开始前查阅本文件，而不是事后。

## Seams：测试放哪里

seam 是观察行为的公共边界：不深入内部就能看到行为变化的接口。测试只放在 seams 上，从不对着内部写。

**只在预先商定的 seams 上测试。** 写任何测试前，先写下要测的 seams 并与用户确认，或采用已批准 Spec/plan 的验收面；未确认的 seam 上不写测试。问法："公共接口是什么？哪些 seams 值得测？"

好测试读起来像规约（"user can checkout with valid cart"），能在重构后存活。好/坏对照见 `references/tests.md`；mock 边界见 `references/mocking.md`。

## 循环规则

- **先红后绿。** 先写失败测试，再写刚好让它通过的实现；不预写未来测试，不加投机功能。
- **一次一片。** 每个循环一个 seam、一个测试、一段最小实现；垂直切片而非横向铺开——先写全部测试再写全部实现，验证的是想象中的行为。
- **重构不在循环内。** 行为变绿后的结构收敛由 review 识别、授权后另行整理，不混进 red-green 循环。

## 反模式

- **实现耦合**：mock 内部协作者、测私有方法、走旁路验证。识别信号：行为没变、重构后测试却红了。
- **同义反复**：断言用实现自己的方式重算期望值，构造性通过。期望值必须来自独立真相：已知正确的字面量、算好的例子、Spec。
- **横向切片**：见"一次一片"。

环境有 `CONTEXT.md` 时先读以对齐领域语言，遵守所在区域 ADR。