tdd

Files (4)

• SKILL.md
• openai.yaml · agents/
• mocking.md
• tests.md

SKILL.md (first lines)

# 测试驱动开发

TDD 是 red → green 循环。本 skill 是让该循环产出值得保留的测试的参考：什么是好测试、测试放在哪、反模式，以及循环规则。每一节在每一轮都适用——在循环之前和之中查阅，而不是之后。

探索代码库时，阅读 `CONTEXT.md`（若存在），使测试名和接口词汇与项目的领域语言一致，并尊重你所触及区域的 ADRs。

## 什么是好测试

测试通过公共接口验证行为，而不是实现细节。代码可以完全改写；测试不该跟着碎。好测试读起来像一份 specification——"user can checkout with valid cart" 精确告诉你存在什么能力——并且能熬过重构，因为它不关心内部结构。

示例见 [tests.md](tests.md)，mocking 指南见 [mocking.md](mocking.md)。

## Seams —— 测试放在哪

**Seam** 是你测试所在的公共边界：在那里观察行为而不伸进内部。测试活在 seams 上，从不对着内部。

**只在预先约定的 seams 上测试。** 写任何测试之前，写下被测的 seams 并与用户确认。未确认的 seam 上不写测试。你没法测尽一切——事先约定 seams，才能把测试精力落在关键路径和复杂逻辑上，而不是每个边角情况。

问：「公共接口是什么，我们应该在哪些 seams 上测试？」

当该接口本身的形态还成问题时——模块有多深、seam 该落在哪、接口该暴露什么——用 `/codebase-design` skill 获取词汇。它是 module、interface、depth、seam、adapter、leverage 和 locality 这些术语的共享来源，是查阅用的参考，不是要跑的会话。

## 反模式

- **Implementation-coupled** —— mock 内部协作者、测试私有方法，或通过旁路验证（查数据库而不是用接口）。特征：你重构时测试碎了，但行为没变。
- **Tautological** —— 断言用代码同样的方式重算期望值（`expect(add(a, b)).toBe(a + b)`、按同样方式手推出来的 snapshot、常量断言等于自己），所以它构造上就会通过，永远无法与代码不一致。期望值必须来自独立的真相来源——已知正确的字面量、演算过的例子、spec。
- **Horizontal slicing** —— 先写完全部测试，再写全部实现。批量测试验证的是*想象中的*行为：你测的是事物的*形态*而不是面向用户的行为，测试对真实变化变得不敏感，并且在理解实现之前就锁定了测试结构。改为用 **vertical slices** —— 一个测试 → 一次实现 → 重复，每个测试都是一颗 **tracer bullet**，对上一轮教会你的东西做出响应。

## 循环规则

- **先 red 再 green。** 先写失败的测试，再只写刚好能让它通过的代码。不要预判未来的测试或加入投机功能。
- **一次一个切片。** 每轮一个 seam、一个测试、一份最小实现。
- **重构不是循环的一部分。** 它属于审查阶段（见 `code-review` skill），不属于 red → green 实现循环。

From shenjunjian/matt-skill-cn, MIT.

More from shenjunjian/matt-skill-cn