개발자는 테스트 없이 코드를 작성하다가 디버깅에 시간을 낭비하곤 합니다. 이 스킬은 RED-GREEN-REFACTOR 사이클을 강제하여 신뢰할 수 있는 소프트웨어를 자신감 있게 구축할 수 있도록 합니다.
스킬 ZIP 다운로드
Claude에서 업로드
설정 → 기능 → 스킬 → 스킬 업로드로 이동
토글을 켜고 사용 시작
테스트해 보기
"tdd-workflow" 사용 중입니다. 이메일 주소를 검증하는 함수 구현
예상 결과:
- RED 단계: '유효한 이메일 형식을 허용해야 함' 테스트 생성 - 테스트 실패 (아직 구현 없음)
- GREEN 단계: 최소한의 정규식 검증 구현 - 테스트 통과
- REFACTOR 단계: 검증 로직을 별도 함수로 추출, 오류 메시지 개선
"tdd-workflow" 사용 중입니다. 사용자 조회에서 null 포인터 예외 수정
예상 결과:
- RED 단계: null 포인터 예외를 재현하는 테스트 - 실패 확인
- GREEN 단계: 사용자 속성 액세스 전 null 체크 추가 - 테스트 통과
- REFACTOR 단계: 코드베이스 전체에서 사용되는 재사용 가능한 null-safe 조회 헬퍼 생성
보안 감사
안전All static analysis findings are false positives. The arrow character (→) was misidentified as shell backtick execution. References to 'crypto' and 'reconnaissance' are pattern matching errors on plain text documentation. This is a safe TDD methodology guide. External commands are legitimately used for running test suites.
위험 요인
⚙️ 외부 명령어 (1)
품질 점수
만들 수 있는 것
새 기능 개발
테스트를 먼저 작성한 후 각 테스트를 통과하는 최소한의 코드를 구현하여 신뢰할 수 있는 기능을 구축합니다.
회귀 방지 기능을 갖춘 버그 수정
버그를 재현하는 테스트를 작성하고 수정한 후, 버그가 수정된 상태로 유지된다는 확신을 가지고 리팩토링합니다.
팀 코드 품질 개선
다른 에이전트가 테스트 작성, 코드 구현, 리팩토링을 담당하는 다중 에이전트 TDD 패턴을 사용합니다.
이 프롬프트를 사용해 보세요
[동작 설명] 함수를 구현하고 싶습니다. TDD 의 RED 단계에 따라 실패하는 테스트를 먼저 작성하세요. 테스트는 예상 동작을 명확히 설명해야 합니다.
TDD 를 사용하여 [기능] 을 구현합시다. 1 단계: 실패하는 테스트 작성. 2 단계: 통과하는 최소한의 코드 작성. 3 단계: 명확성을 위한 리팩토링. 각 단계를 안내해주세요.
이 테스트를 검토하고 AAA 패턴 (Arrange, Act, Assert) 을 사용하여 재구성하세요. 어떤 데이터를 설정해야 하는지, 어떤 코드가 실행되는지, 어떤 결과를 검증해야 하는지 식별합니다.
[기능] 에 대한 다중 에이전트 TDD 세션을 실행하세요. 에이전트 A 는 실패하는 테스트를 작성하고, 에이전트 B 는 통과하도록 구현하고, 에이전트 C 는 리팩토링합니다. 각 단계 간 인계를 조정합니다.
모범 사례
- 구현 코드를 작성하기 전에 항상 테스트가 실패하는지 확인하세요 - 이는 테스트가 작동함을 검증합니다
- 테스트당 하나의 어설션을 작성하여 실패를 격리하고 의도를 명확히 합니다
- 각 RED-GREEN-REFACTOR 사이클 완료 후 커밋하여 작고 검토 가능한 변경 사항을 유지합니다
피하기
- 테스트가 실패하기 전에 코드 작성 - TDD 의 목적을 무너뜨리며 종종 요구사항을 이해하지 못했음을 의미합니다
- private 메서드 이름과 같은 구현 세부사항 테스트 - 테스트는 내부 구조가 아닌 동작을 검증해야 합니다
- 테스트당 여러 어설션 - 실패를 모호하게 만들고 단일 책임 원칙을 위반합니다