Back to Details

tdd

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

测试驱动开发（Test-Driven Development）

Test-Driven Development (TDD)

TDD 是红 → 绿的循环。本技能是让这个循环产出值得保留的测试的参考：好测试是什么、测试放在哪里、反模式有哪些、循环的规则是什么。每一节在每一个循环中都适用——在循环之前和之中查阅它们，而不是之后。
探索代码库时，读 
CONTEXT.md
（如果存在），让测试名称和接口词汇与项目的领域语言一致，并尊重你正在触碰的区域的 ADR。
TDD is a red → green cycle. This skill is a reference for making this cycle produce tests worth keeping: what a good test is, where to place tests, what anti-patterns exist, and what the rules of the cycle are. Each section applies in every cycle—consult them before and during the cycle, not after.
When exploring the codebase, read 
CONTEXT.md
(if it exists), align test names and interface vocabulary with the project's domain language, and respect the ADRs of the area you're touching.

好测试是什么

What Makes a Good Test

测试通过公共接口验证行为，而不是实现细节。代码可以彻底改变；测试不应该。好测试读起来像一份规格——"用户可以用有效购物车结账"精确地告诉你存在什么能力——而且因为它不关心内部结构，能在重构中存活。
示例见 tests.md，mocking 指南见 mocking.md。
Tests validate behavior through public interfaces, not implementation details. Code can change completely; tests should not. A good test reads like a specification—"Users can check out with a valid cart" tells you exactly what capability exists—and because it doesn't care about internal structure, it survives refactoring.
See tests.md for examples, and mocking.md for the mocking guide.

接缝——测试放在哪里

Seams – Where to Place Tests

**接缝（seam）**是你测试所在的公共边界：在不伸手进内部的情况下观察行为的接口。测试住在接缝处，绝不对着内部。
只在预先约定的接缝处测试。 写任何测试之前，写下要测试的接缝并与用户确认。没有测试写在未经确认的接缝上。你不可能测试所有东西——提前约定接缝，正是让测试精力落在关键路径和复杂逻辑上、而不是每个边界情况上的方法。
问："公共接口是什么，我们应该测试哪些接缝？"
当接口的形态本身存疑时——模块该有多深、接缝该在哪里、接口应该暴露什么——用 
/codebase-design
技能来获得词汇。它是 module、interface、depth、seam、adapter、leverage、locality 这些词的共享来源，是一份供查阅的参考，而不是要跑的一场会话。
Seams are the public boundaries where your tests live: interfaces where you can observe behavior without reaching into the internals. Tests live at seams, never against internals.
Only test at pre-agreed seams. Before writing any test, write down the seam to test and confirm with the user. No tests are written on unconfirmed seams. You can't test everything—agreeing on seams upfront is the way to focus testing effort on critical paths and complex logic, not every edge case.
Ask: "What are the public interfaces, and which seams should we test?"
When the shape of interfaces is in question—how deep modules should be, where seams should be, what interfaces should expose—use the 
/codebase-design
skill to get vocabulary. It is the shared source for terms like module, interface, depth, seam, adapter, leverage, locality, a reference to consult, not a session to run.

反模式

Anti-Patterns

  • 与实现耦合（Implementation-coupled） — mock 内部协作者、测试私有方法、或通过旁路渠道验证（查数据库而不是用接口）。识别信号：重构时行为没变，测试却挂了。
  • 同义反复（Tautological） — 断言用与代码相同的方式重新计算期望值（
    expect(add(a, b)).toBe(a + b)
    、以同样方式手工推导出的快照、断言常量等于自身），所以它构造性地通过，永远不可能与代码相左。期望值必须来自独立的真实来源——已知正确的字面量、手算的示例、规格。
  • 水平切片（Horizontal slicing） — 先写完所有测试，再写所有实现。成批的测试验证的是想象出来的行为：你测试的是事物的形状而不是面向用户的行为，测试对真实变化变得不敏感，而且你在理解实现之前就锁定了测试结构。改用垂直切片——一个测试 → 一个实现 → 重复，每个测试都是一颗示踪子弹，对上一循环教会你的东西作出回应。
  • Implementation-coupled — Mock internal collaborators, test private methods, or validate through bypass channels (check the database instead of using the interface). Identification signal: Tests fail during refactoring even though behavior hasn't changed.
  • Tautological — Assertions recalculate expected values in the same way as the code (
    expect(add(a, b)).toBe(a + b)
    , snapshots manually derived the same way, asserting constants equal to themselves), so they pass constructively and can never contradict the code. Expected values must come from independent, real sources—known correct literals, manually calculated examples, specifications.
  • Horizontal slicing — Write all tests first, then all implementations. Batches of tests validate imagined behavior: you're testing the shape of things instead of user-facing behavior, tests become insensitive to real changes, and you lock in test structure before understanding the implementation. Instead, use vertical slicing—one test → one implementation → repeat, where each test is a tracer bullet that responds to what the previous cycle taught you.

循环的规则

Rules of the Cycle

  • 先红后绿。 先写会失败的测试，然后只写恰好能通过它的代码。不要预想未来的测试，也不要加投机性的功能。
  • 一次一个切片。 每个循环一个接缝、一个测试、一个最小实现。
  • 重构不是循环的一部分。 它属于审查阶段（见 
    code-review
    技能），不属于红 → 绿实现循环。
  • Red before green. Write a test that fails first, then write only the code exactly needed to pass it. Don't anticipate future tests, and don't add speculative features.
  • One slice at a time. One seam, one test, one minimal implementation per cycle.
  • Refactoring is not part of the cycle. It belongs to the review phase (see the 
    code-review
    skill), not the red → green implementation cycle.