tdd-identify

One-line summary

Diagnose which TDD technique fits the current moment — the right Beck move depends on whether you know what to type, whether the test is too big, whether the dependency is too slow, or whether you've just found a bug.

When to use this skill

A test is red and you're not sure how to make it green.
You can see the implementation but unsure whether to type it directly or fake-then-generalize.
You're staring at the next test and can't decide which one to write.
A test is hitting a slow / external dependency and you're not sure how to isolate.
You just fixed a bug and aren't sure what kind of test to leave behind.

When NOT to use this skill

You haven't decided whether to use TDD at all → that's the workflow question, see tdd-red-green-refactor (and Superpowers' test-driven-development if installed).
You know exactly which technique to apply → go directly to that skill.
Domain-modeling question that's masquerading as a TDD question → route to ddd-design.

Core content

Walk the stuck moment through these questions, in this order:

1. Is the test red and you don't know what code to write?

I know exactly what the production code looks like → tdd-obvious-implementation. Just type it.
I know the answer for this specific input but not the general algorithm → tdd-fake-it. Return a constant; let the next test force the generalization.
I've faked it and now need to generalize → tdd-triangulate. Write a second test with different inputs that the fake can't satisfy.

2. The test you're trying to write feels too big?

I can't see how to write the production code for this test → tdd-child-test. Set the big test aside; write a smaller test you can complete; come back to the big one with new understanding.
I've got a backlog of tests and don't know which to write next → tdd-one-step-test. Pick the one that teaches you the most while still being implementable quickly.

3. The test is touching something slow / external / unreliable?

Database, network, file system, time → tdd-mock-object. Use a test double; make sure you also test against the real thing somewhere.
Tests pass when run alone but fail when run together → tdd-test-isolation. Each test must own its fixture; no shared mutable state.

4. You're working with a third-party library you don't fully understand?

I'm not sure how this library behaves; the docs aren't enough → tdd-learning-test. Write tests against the library to discover its behavior AND catch breakage in upgrades.

5. You just fixed a bug?

Every bug gets a test → tdd-regression-test. Write the test that would have caught the bug; commit it alongside the fix.

6. Reviewing tests for smells?

Slow tests, flaky tests, interdependent tests, mocking what you don't own, testing the framework instead of your code → audit via tdd-anti-patterns.

Decision heuristics

Beck's own decision tree (paraphrased): "If you know what to type, type it (obvious-implementation). If you don't but you know the answer for one case, fake-it. If neither, triangulate. If you're still stuck, take a shower."
Reach for mock-object reluctantly. Mocks couple tests to implementation; only mock at the boundary (external services, slow resources, time).
When in doubt about test scale, child-test always — smaller tests teach faster.

Anti-patterns

Treating each technique as a "level you graduate from". obvious-implementation isn't better than fake-it; they're for different moments. Senior practitioners use all of them.
Mocking everything by reflex. Mocks are a last resort, not a default.
Skipping the regression-test step after a fix. The bug returns; you have nothing to catch it.

References

Kent Beck, Test-Driven Development By Example (Addison-Wesley, 2002) — Part III is the canonical pattern catalog.
Beck's own "rules" essay and conference talks on TDD.

About this skill