← ClaudeAtlas

lfe-tddlisted

Red-green-refactor quality pass on code the Builder just wrote. Use in the Builder sub-pipeline after lfe-builder completes implementation.
StChiotis/Claude-LFE · ★ 2 · AI & Automation · score 68
Install: claude install-skill StChiotis/Claude-LFE
# LFE TDD ## Position in Pipeline - **Phase**: 2 (Builder sub-pipeline, Step 2) - **Persona**: Builder - **Input**: `active_plan.md` + `.plans/builder_done.md` (resume marker — confirms implementation phase completed) + code written by lfe-builder - **Output**: `.plans/tdd_report.md` ## Philosophy **Core principle**: Tests verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't. **Good tests** are integration-style: they exercise real code paths through public APIs. They describe _what_ the system does, not _how_. A good test reads like a specification. **Bad tests** are coupled to implementation. They mock internal collaborators, test private methods, or verify through external means. Warning sign: your test breaks when you refactor, but behavior hasn't changed. See [tests.md](./tests.md), [mocking.md](./mocking.md) for examples. ## Anti-Pattern: Horizontal Slices **Write incrementally — one test, then its implementation — rather than all tests up front.** Writing all tests first is "horizontal slicing." **Correct approach**: Vertical slices via tracer bullets. One test → one implementation → repeat. ``` WRONG (horizontal): RED: test1, test2, test3, test4, test5 GREEN: impl1, impl2, impl3, impl4, impl5 RIGHT (vertical): RED→GREEN: test1→impl1 RED→GREEN: test2→impl2 RED→GREEN: test3→impl3 ``` ## Workflow ### 1. Review Read `active_plan.md` and review what the Builder implemented. Identify behavi