Test-Driven Development

• · TD1 — Write the test before the implementation; run it and confirm it fails for the expected reason (Red).
• · TD2 — Write the minimum code to make the test pass (Green) — no extra generality, no unrelated improvements.
• · TD3 — Refactor only with passing tests as a safety net (Refactor); never refactor and add behavior in the same step (two hats).
• · TD4 — Each cycle is small — minutes, not hours; a test that requires an hour of implementation to pass is too large, split it.
• · TD5 — Tests describe behavior (inputs → outputs/effects), not implementation details, so refactoring doesn't require rewriting tests.

• · Wrote code before a test exists for it? Stop, revert conceptually, write the test first — retrofitted tests tend to just confirm what the code already does, not what it should do.
• · A test that passes on the first run without ever seeing it fail → suspicious; verify it can actually fail (mutate the code briefly to confirm).
• · Struggling to write a test for a unit → often means the unit has too many responsibilities or hidden dependencies; that's a design signal, not just a testing inconvenience.
• · Implementation feels like "cheating" the test (hardcoded return value) → add a second test with different input to force generalization.
• · A refactor step introduces new failing tests → stop, that's a behavior change smuggled into refactoring; separate it out.

• · Test-after theater — writing implementation first, then tests that just confirm what the code happens to do, providing no real design pressure or regression safety for actual intended behavior.
• · Never-red tests — a test that's never been watched to fail, quietly not actually testing anything (bad assertion, wrong setup).
• · Implementation-detail assertions — tests checking private internals/call counts instead of observable behavior, breaking on every harmless refactor.
• · Giant cycles — a single Red-Green step spanning hours of implementation, defeating the tight-feedback-loop purpose of TDD.
• · Refactor-with-new-behavior — sneaking in a feature change during what's supposed to be a pure refactor step, with no test coverage for the new behavior.

• [ ] New logic-bearing code has tests reflecting Red-Green-Refactor (or equivalent evidence). (TD-E1)
• [ ] Implementation is minimal to the test's requirement, no speculative extras. (TD-E2)
• [ ] Refactor steps don't introduce new failing tests. (TD-E3)
• [ ] Tests assert behavior, not implementation internals. (TD-E4)
• [ ] Commit history reflects distinguishable test/implementation steps where practical. (TD-E5)

• Test-Driven Development: By Example

Este pack cita las siguientes fuentes registradas en el índice bibliográfico:

• bookExtreme Programming ExplainedKent Beck. Addison-Wesley
• bookTest-Driven Development: By ExampleKent Beck. Addison-Wesley