← ClaudeAtlas

test-driven-developmentlisted

Use when implementing any feature or bugfix, before writing implementation code
FrogBaek/cue · ★ 0 · AI & Automation · score 63
Install: claude install-skill FrogBaek/cue
# Test-Driven Development (TDD) **Speak the repository's language.** `.cue/dev/config`'s `language` decides what you write to the user, and the session hook states it at the top of every session — this skill runs no cue-dev script of its own, so nothing repeats it here. This skill body is English because it is the plugin's source, not because it is your output. Code, identifiers, paths, test names and commit markers stay exactly as written. ## Overview Write the test first. Watch it fail. Write minimal code to pass. **Core principle:** If you didn't watch the test fail, you don't know if it tests the right thing. **Violating the letter of the rules is violating the spirit of the rules.** ## When to Use **Always:** - New features - Bug fixes - Refactoring - Behavior changes **Exceptions (ask your human partner):** - Throwaway prototypes - Generated code - Configuration files Thinking "skip TDD just this once"? Stop. That's rationalization. ## The Iron Law ``` NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST ``` Write code before the test? Delete it. Start over. **No exceptions:** - Don't keep it as "reference" - Don't "adapt" it while writing tests - Don't look at it - Delete means delete Implement fresh from tests. Period. ## Red-Green-Refactor ```dot digraph tdd_cycle { rankdir=LR; red [label="RED\nWrite failing test", shape=box, style=filled, fillcolor="#ffcccc"]; verify_red [label="Verify fails\ncorrectly", shape=diamond]; green [label="GREEN