Menu
Write tests before implementation to drive design and prove correctness
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Build UIs that work for all users including keyboard navigation, screen readers, and WCAG 2.2
Design multi-agent systems with robust tool interfaces, state management, and failure handling
Build ML systems with disciplined training, evaluation, deployment, and safety practices
Design APIs that are stable, ergonomic, and evolvable
Design systems at the right scale with explicit trade-off documentation
Design services that are reliable, observable, secure, and maintainable
| name | test-driven-development |
| description | Write tests before implementation to drive design and prove correctness |
| difficulty | senior |
| domains | ["general"] |
TDD is not about testing โ it's about design. Writing tests first forces you to define the interface before the implementation, catches over-engineering, and creates a living specification. The test suite is proof of correctness, not evidence of effort.
Write the simplest test that captures one behavior. Run it. It must fail. If it passes without implementation, the test is wrong.
Write the least code that makes the test pass. Do not add functionality that isn't tested yet. Resist the urge to generalize.
Now that the test passes, clean the implementation. Extract duplication, improve names, simplify logic. Run tests after each change.
Add one behavior at a time. The test suite grows incrementally.
After the happy path works: test empty inputs, boundary values, error conditions, concurrent access, and failure modes.
Tests should describe what the function does, not how it does it. Avoid testing internal state โ test inputs and outputs.
Each test must run in isolation. No shared mutable state between tests. Tests that require a specific order are fragile.
A test that is wrong is worse than no test. Delete tests that no longer represent the system. Update tests when behavior intentionally changes.
"I'll add tests after I'm done implementing" Tests written after implementation test what the code does. Tests written before implementation test what the code should do. These are different.
"TDD is too slow" TDD is slower in the first hour and faster in the second day. Debugging a test-free codebase is not faster โ it's deferred pain.
"This code is too simple to test" Code simple enough to not test is simple enough to test in 2 minutes.
"Mocking makes the tests too complex" If mocking is hard, your dependencies are too tight. Use the test complexity as a design signal.
