tdd

tdd skill 개요

tdd는 red-green-refactor 루프로 기능을 만들고 버그를 고치는 Test-Driven Development skill입니다. 구현보다 동작에 테스트가 맞춰지도록 유지하는 실용적인 tdd 가이드를 원하는 엔지니어에게 가장 잘 맞습니다. 리팩터링이 잦고, 인터페이스가 중요하며, 취약한 테스트 때문에 속도가 떨어지는 코드베이스에서 작업 중이라면, 이 skill은 변화에도 버티는 테스트를 작성하는 데 도움을 줍니다.

핵심 작업은 단순합니다. 대략적인 기능 아이디어를 안전하게 검증 가능한 작은 단계들의 시퀀스로 바꾸는 것입니다. tdd skill은 특히 테스트 자동화 작업, 통합 스타일 테스트, 그리고 경계가 더 분명할수록 이득이 큰 코드에 유용합니다. 가장 강한 원칙은 public interface를 통해 테스트하고, 실제 시스템 경계에서만 mock을 쓰라는 것입니다.

tdd의 용도

새로운 동작, 버그 수정, 또는 안전망이 필요한 리팩터링에 test-first 워크플로를 쓰고 싶을 때 tdd를 사용하세요. 기대 결과는 이미 알고 있지만 가장 깔끔한 구현 경로는 아직 정하지 못했을 때 잘 맞습니다.

이 tdd skill이 다른 점

이 repo는 단순히 “먼저 테스트를 작성하라”는 수준이 아닙니다. 수평으로 쪼개는 방식을 피하고, 동작 중심 테스트를 선호하며, 테스트하기 쉬운 인터페이스를 설계하라는 구체적인 원칙을 밀어줍니다. 그래서 빠르지만 불안정한 테스트가 아니라 오래 버티는 테스트가 필요할 때, 이 tdd skill은 일반적인 프롬프트보다 훨씬 유용합니다.

tdd에 맞지 않는 경우

짧게 끝내는 단발성 unit test, 임시 스크립트, 또는 내부 호출을 mock으로 촘촘히 검증하는 용도라면 이 tool은 아마 맞지 않습니다. 이 skill은 나중에 리팩터링할 가능성이 있는 소프트웨어, 그리고 테스트 개수보다 테스트 품질이 더 중요한 상황을 겨냥합니다.

tdd skill 사용 방법

skill을 설치하고 불러오기

TDD install 단계에서는 directory의 install command를 사용한 뒤, 먼저 SKILL.md를 여세요. 그 다음에는 실제 출력 품질을 좌우하는 규칙이 담긴 tests.md, mocking.md, interface-design.md, refactoring.md, deep-modules.md를 읽으세요.

해결책이 아니라 동작을 전달하기

가장 좋은 tdd usage는 사용자에게 보이는 결과, 입력, 기대 결과로 시작합니다. 강한 프롬프트 예시는 다음과 같습니다.

• “checkout 검증을 추가해서, 유효하지 않은 cart는 명확한 error를 반환하고 유효한 cart는 결제를 완료하게 해줘”
• “중복 이메일 때문에 account가 두 개 만들어지는 bug를 고쳐줘”
• “public service interface를 사용해서 payment API에 대한 retry flow 테스트를 작성해줘”

약한 프롬프트 예시는 다음과 같습니다.

• “checkout 테스트를 작성해줘”
• “이 module을 더 테스트하기 쉽게 만들어줘”
• “database를 mock하고 function이 호출됐는지 확인해줘”

red-green-refactor 루프를 따르기

가장 작게 관찰 가능한 동작부터 시작해, 그것을 증명하는 실패 테스트 하나를 작성하고, 통과할 최소한의 코드를 구현한 다음, 테스트가 green인 상태를 유지하면서 refactor하세요. 테스트를 먼저 한꺼번에 몰아 만들고 구현을 나중에 몰아서 하는 방식은 피해야 합니다. 이 skill은 수평적 분할이 실제로 테스트된 behavior가 아니라 상상한 behavior를 만들기 쉽다고 분명히 경고합니다.

이 파일들을 먼저 읽기

실제로 작업할 때는 다음 순서로 우선순위를 두세요.

• 철학과 워크플로를 담은 SKILL.md
• 좋은 테스트 패턴과 나쁜 테스트 패턴을 비교하는 tests.md
• boundary-only mocking을 설명하는 mocking.md
• 테스트하기 쉬운 코드를 만드는 interface-design.md
• 첫 번째 green pass 이후 개선할 내용을 다루는 refactoring.md

tdd skill FAQ

tdd는 unit test에만 쓰나요?

아닙니다. 이 tdd skill은 public interface를 통한 integration-style test를 선호합니다. 그래서 고립된 unit-heavy 방식보다 test automation과 behavior testing에 더 잘 맞는 경우가 많습니다.

모든 것을 mock해야 하나요?

아닙니다. 이 tdd guide의 핵심 규칙은 external API, time, randomness, 그리고 경우에 따라 file system이나 database 같은 system boundary에서만 mock을 쓰라는 것입니다. 테스트를 통과시키기 위해 자기 자신의 module까지 mock하지 마세요.

초보자도 tdd를 사용할 수 있나요?

네, 기대 동작을 명확히 설명할 수 있다면 가능합니다. 가장 큰 학습 곡선은 문법이 아니라, 적절한 boundary를 고르고 implementation-detail 테스트를 피하는 데 있습니다.

tdd는 일반 프롬프트와 어떻게 다른가요?

일반 프롬프트는 단지 컴파일되는 테스트를 만들 수 있습니다. 반면 tdd skill은 더 강한 의견을 갖고 있습니다. behavior-first 테스트, 작은 증분, 그리고 리팩터링 중에도 테스트를 안정적으로 유지하는 interface design을 밀어줍니다.

tdd skill 개선 방법

더 선명한 입력으로 시작하기

tdd는 behavior, boundary, constraint를 함께 넣을 때 더 좋은 결과를 줍니다. 예를 들어 “실제 service wrapper를 사용하는 재시도 가능한 email sender를 만들되, time과 external provider는 mock해줘”라고 말하는 편이 “이걸 테스트하기 쉽게 만들어줘”라고 하는 것보다 훨씬 낫습니다.

흔한 실패 모드 주의하기

가장 흔한 실수는 과도한 mock, private method 테스트, 그리고 코드가 어떻게 동작하는지 설명할 뿐 사용자가 무엇을 보는지는 놓치는 테스트입니다. 첫 초안이 너무 implementation-aware하게 느껴진다면, public API와 관찰 가능한 결과를 명시하도록 프롬프트를 고치세요.

test에서 design으로 반복 개선하기

첫 결과를 받은 뒤에는 실패를 활용해 interface design을 개선하세요. parameter를 더 작게 나누고, return value를 더 분명하게 만들고, side effect를 줄이는 방향입니다. 여전히 테스트하기 어렵다면, 문제는 테스트가 아니라 API 모양일 수 있습니다.

green 이후에는 refactor 목표를 요청하기

동작이 커버된 다음에는 duplication, 긴 method, shallow module, feature envy, primitive obsession 같은 항목을 짚어 달라고 요청하세요. 바로 이 지점에서 tdd skill의 추가 가치가 드러납니다. 단순히 “테스트를 통과하는 코드”를 넘어서, 계속 테스트하기 쉬운 더 깔끔한 design으로 옮겨 가도록 돕기 때문입니다.