tdd
Drive a change through a red-green-refactor loop - failing test first, minimal code to pass, then clean up. Use when implementing a feature or fixin…
它会碰到什么
这一栏是扫描器报的事实，不是结论。命中多不等于有毒（安全工具、规则库、示例脚本本来就会包含危险写法），命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系，需要你自己看。
技能内容
tdd
The agent codes better with a tight feedback loop than with a long
specification. A failing test is the tightest loop there is: it states the
target, and the target either goes green or it does not.
The loop
- Red. Write one failing test that states the next slice of behavior.
Run it. Confirm it fails for the right reason - a test that passes before
you write the code is testing nothing. If it errors instead of failing on
the assertion, fix the test setup first.
- Green. Write the least code that makes the test pass. Not the general
solution, not the abstraction - the minimal move. Run the test. Green.
- Refactor. Now clean up with the test as a net: remove duplication,
name things, simplify. Re-run after every edit. Behavior is frozen; only
the shape changes.
- Repeat for the next slice. Small slices. The rate of feedback is the
speed limit - never take on a step too big to hold a single test.
What makes a test worth writing
- Tests behavior, not implementation. Assert on the observable result,
not on which private method got called. A test that breaks on every
refactor is a liability.
- One reason to fail. Each test pins one behavior. When it goes red you
should know what broke without reading the body.
- Real seams, minimal mocks. Mock at the system boundary (network, clock,
filesystem), not internal collaborators. A test that mocks the thing under
test asserts nothing.
- No tautologies. A test that restates the implementation (
expect(x).toBe(x)
after setting x) verifies nothing. Assert the value the behavior should produce.
When to reach for it
Reach for TDD when the behavior is specifiable and a test can pin it: business
logic, parsers, state machines, bug fixes (write the failing case first, then
fix). Skip it for pure exploration, throwaway spikes, and layout-only UI where
a test asserts nothing a human would not eyeball.
Output contract
Show each red-green transition, not just the final green. If a test is hard to
write, say what the difficulty reveals about the design - untestable code is
usually badly-seamed code, and that is a finding, not an obstacle.
想直接用这个技能？
本站把开放许可（MIT / Apache 等）的技能按仓库打包整理到网盘，点一下转存到你自己的网盘，不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接，不打包。