← 技能图谱 · tests · mocking

name	tdd
description	Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
触发词	测试驱动开发。当用户想以测试为先的方式构建功能或修复 bug、提到「红-绿-重构」，或想要集成测试时使用。

tdd

Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

TDD is the red → green loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Every section applies on every cycle — consult them before and during the loop, not after.

TDD 是红 → 绿的循环。本技能是让该循环产生值得保留的测试的参考指南：好测试的标准、测试的位置、反模式以及循环规则。每个部分在每个周期都适用——在循环之前和期间查阅它们，而不是之后。

When exploring the codebase, read CONTEXT.md (if it exists) so test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.

探索代码库时，阅读 CONTEXT.md（如果存在），使测试名称和接口词汇与项目的领域语言匹配，并尊重你触及区域的 ADR。

What a good test is

什么是好测试

Tests verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't. A good test reads like a specification — "user can checkout with valid cart" tells you exactly what capability exists — and survives refactors because it doesn't care about internal structure.

测试通过公共接口验证行为，而不是实现细节。代码可以完全改变；测试不应该。一个好的测试读起来像一份规格说明——"用户可以使用有效购物车结账"确切地告诉你存在什么能力——并且能经受重构，因为它不关心内部结构。

See tests.md for examples and mocking.md for mocking guidelines.

参见 tests.md 获取示例，mocking.md 获取模拟指南。

Seams — where tests go

接缝——测试的位置

A seam is the public boundary you test at: the interface where you observe behavior without reaching inside. Tests live at seams, never against internals.

接缝是你进行测试的公共边界：一个无需触及内部就能观察行为的接口。测试存在于接缝处，绝不针对内部。

Test only at pre-agreed seams. Before writing any test, write down the seams under test and confirm them with the user. No test is written at an unconfirmed seam. You can't test everything — agreeing the seams up front is how testing effort lands on the critical paths and complex logic instead of every edge case.

只在预先约定的接缝处测试。 在编写任何测试之前，写下被测的接缝并与用户确认。没有测试写在未经确认的接缝上。你无法测试所有东西——事先约定接缝，测试工作才能落在关键路径和复杂逻辑上，而不是每种边缘情况。

Ask: "What's the public interface, and which seams should we test?"

请问："公共接口是什么，我们应该测试哪些接缝？"

Anti-patterns

反模式

Implementation-coupled — mocks internal collaborators, tests private methods, or verifies through a side channel (querying the database instead of using the interface). The tell: the test breaks when you refactor but behavior hasn't changed.
Tautological — the assertion recomputes the expected value the way the code does (expect(add(a, b)).toBe(a + b), a snapshot derived by hand the same way, a constant asserted equal to itself), so it passes by construction and can never disagree with the code. Expected values must come from an independent source of truth — a known-good literal, a worked example, the spec.
Horizontal slicing — writing all tests first, then all implementation. Bulk tests verify imagined behavior: you test the shape of things rather than user-facing behavior, the tests go insensitive to real changes, and you commit to test structure before understanding the implementation. Work in vertical slices instead — one test → one implementation → repeat, each test a tracer bullet that responds to what the last cycle taught you.

耦合实现细节——模拟内部协作者、测试私有方法，或通过旁路通道验证（查询数据库而非使用接口）。征兆：重构时测试失败，但行为并未改变。
同义反复——断言以代码的相同方式重新计算期望值（expect(add(a, b)).toBe(a + b)、以同样方式手工推导的快照、一个断言等于自身的常量），因此它按构造通过，永远无法与代码产生分歧。期望值必须来自独立的真值来源——已知良好的字面量、经过手工计算的示例、规格说明。
水平切片——先写完所有测试，再写所有实现。批量测试验证的是想象中的行为：你测试的是事物的形态而非面向用户的行为，测试对真实变化变得不敏感，并且你在理解实现之前就确定了测试结构。应当使用垂直切片——一个测试 → 一个实现 → 重复，每个测试都是一颗曳光弹，回应上一周期教会你的东西。

Rules of the loop

循环规则

Red before green. Write the failing test first, then only enough code to pass it. Don't anticipate future tests or add speculative features.
One slice at a time. One seam, one test, one minimal implementation per cycle.
Refactoring is not part of the loop. It belongs to the review stage (see the code-review skill), not the red → green implementation cycle.

红在前，绿在后。 先写失败的测试，然后只写足够让它通过的代码。不要预测未来的测试或添加推测性的功能。
一次一片。 每个周期一个接缝、一个测试、一个最小实现。
重构不属于循环的一部分。 它属于审查阶段（参见 code-review 技能），而不是红 → 绿的实现周期。