메뉴
Write tests before implementation to drive design and prove correctness
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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.
