Ctrl C V Tdd

---
name: ctrl-c-v-tdd
description: |
  Test-pattern doctrine. Tests are copyable from
  ~/.claude/patterns/tests/, three categories: input boundary,
  contract, effect. Make sure to consult this skill whenever code
  changes touch a boundary where someone else's code meets yours,
  even if the user doesn't say "test" or "TDD" — Claude tends to
  ship untested boundary code, and this skill prevents the Saturday
  phone call.
  TRIGGER when: code under change has external callers (other
  modules, cron, CLI, HTTP/RPC clients, "外部调用", "被外部调用");
  persists state (DB write, file write, redis/cache, session
  storage, anything that survives the request); calls third-party
  API/SDK; task is classified as LARGE per ctrl-c-v sizing (4+
  files, new capability, new architecture, new external contract)
  — LARGE always triggers TDD regardless of caller scope; user
  mentions tests, TDD, 测试, boundary, contract, mock, fixture,
  red/green; business domain involves payments, queues, webhooks,
  auth, external integration.
  SKIP when: code change is purely internal helpers used only by
  caller in same file; pure UI rendering with no validation/state;
  accessor < 10 lines with no if/loop/exception; one-file fix that
  ctrl-c-v classifies as SMALL.
  Examples that trigger: "implement Stripe webhook handler",
  "add retry to the upload pipeline", "this database migration",
  "build a multi-step checkout form with validation across steps".
  Examples that skip: "rename this private function", "fix
  formatting in style.css".
extends: ctrl-c-v
---

# Ctrl+C Ctrl+V — TDD Extension

You are the same engineer. Same Friday flight to the Alps. Same system.
You learned one thing the hard way: the code that gets you called back
on Saturday is never the code you wrote — it is the code you forgot to
test at the boundary.

So you built a second pattern library. Tests, like code, are copyable.
A test for "rejects bad input" is the same shape whether the input is
an email or a date. You copy, change the assertion, change the fixture,
ship. You do not write every test. You write tests where it matters:
at boundaries where someone else's code meets yours.

---

## § T0 — When TDD activates

The question is never "should I follow TDD?" — it is "who calls this?"

| Caller of the code under change | Tests? |
|---|---|
| Only this file (private helper) | NO |
| Only this module (internal use) | NO unless logic is non-trivial |
| Other modules in this project | YES — contract test |
| External processes, jobs, CLI users | YES — contract + boundary |
| Third-party API or DB (you call out) | YES — effect test (mock the boundary) |
| HTTP / RPC client (you are callee) | YES — contract + boundary + effect |
| Pure UI rendering, no logic | NO |
| UI with state machine or input validation | YES — contract on the logic |

Two-question fallback when the table feels ambiguous:

1. If this returns the wrong value silently, who notices? "Nobody for a week" → write the test.
2. If someone refactors this next month, what tells them they broke it? "Nothing" → write the test.

## § T1 — TDD integrates with task sizing

Same SMALL / MEDIUM / LARGE. TDD slots into each.

- **SMALL** — no tests. § 6 self-review is the gate.
- **MEDIUM** — § T0 decides. If YES: copy test pattern → RED → implement → GREEN → § 6 → § 7.
- **LARGE** — tests required and written FIRST. Active spec lists test cases as part of Plan. Boundary tests all RED before any implementation. Each task in Tasks: turns specific tests GREEN.

When in doubt, the § T0 table decides — not vibes.

## § T2 — Find before you write (test version)

Same hierarchy as § 1. Different library.

```
0. ~/.claude/patterns/tests/INDEX.md → match? → copy that .md
1. THIS PROJECT     grep "TEST PATTERN:" in tests/
2. FRAMEWORK        does the test framework provide this fixture?
3. APPROVED DEPS    approved test helper / mock library?
4. TEMPLATES        tests/templates/ or example test files
5. OFFICIAL DOCS    framework's docs → copy example
6. FROM SCRATCH     last resort → save to patterns/tests/
```

Step 6 has the same tax as § 5: tag, save, index. Details → @${CLAUDE_SKILL_DIR}/playbooks/test-search.md

## § T3 — Test the boundary, not the implementation

Three categories. Pick by what the code does, not by framework.

| Category | Tests this question | Example shape |
|---|---|---|
| **Input boundary** | Does it reject bad input? | empty / null / oversize / wrong type / malicious |
| **Contract** | Does it return what callers expect? | shape, field names, error types, success vs failure |
| **Effect** | Does it produce the right side effect? | DB row, API call, file write, event emitted |

Write ONE of each. Not three of the same kind. Per-category templates → @${CLAUDE_SKILL_DIR}/playbooks/test-boundaries.md

## § T4 — Tests are also patterns

```
# TEST PATTERN: contract — pure function, happy + 2 errors
# USE WHEN: input → output mapping, no side effects
# COPY THIS: change function name, fixture, expected output, error cases
```

Tag, copy, save. Identical mechanics to § 3 and § 5. The library at
`~/.claude/patterns/tests/` is your second library — grepped together
with code patterns, not separately.

Copying a pattern → @${CLAUDE_SKILL_DIR}/playbooks/test-copy.md

When no pattern fits → @${CLAUDE_SKILL_DIR}/playbooks/test-scratch.md

## § T5 — Test self-review

```
□  Test name reads as a sentence: "rejects_empty_email"
□  One test, one assertion focus
□  No test depends on another's order
□  No real network / real DB (mock the boundary)
□  Test fails for the right reason: comment out impl → does it RED?
□  TEST PATTERN tag added if shape is reusable
□  Test file mirrors source (framework convention)
```

Red flag: a test that still passes when you delete the implementation
under test. That test is testing nothing.

Full checklist → @${CLAUDE_SKILL_DIR}/playbooks/test-review.md

## § T6 — LARGE tasks: spec drives tests drives code

LARGE task's Active spec gets one extra subsection:

```
### Test plan
- [ ] T1 boundary: rejects [bad inputs]
- [ ] T2 contract: returns [shape] when [condition]
- [ ] T3 effect: writes [row] to [table] on success
- [ ] T4 effect: does NOT call [external] when [condition]
```

All boundary tests RED before any implementation task starts. Each
task maps to specific tests turning GREEN. "Verify" in Tasks checklist
= "test Tn passes."

LARGE-specific rhythm → @${CLAUDE_SKILL_DIR}/playbooks/test-large.md

---

## — Completion criteria —

**Boundary coverage** — every external caller has a contract test.
Every effect has an effect test.

**Pattern reuse** — second similar test next month: copy, change 5
lines, ship.

**Refactor safety** — colleague rewrites your function next quarter.
Tests catch the break before merge. You stay on the slopes.

---

*See you on the slopes.* ⛷️