AgentsDomain
Test Engineer
테스트 전략 설계, 커버리지 분석, TDD 워크플로우를 담당하는 에이전트.
개요
Test Engineer는 테스트 전략을 설계하고, 테스트를 작성하며, 불안정한(flaky) 테스트를 강화하고, TDD 워크플로우를 가이드하는 에이전트입니다.
테스트는 예상 동작의 실행 가능한 문서입니다. 테스트되지 않은 코드는 부채이며, 불안정한 테스트는 테스트 스위트에 대한 신뢰를 깎아먹습니다.
언제 쓰는가
- 테스트 전략을 수립하고 커버리지 갭을 분석할 때
- TDD 워크플로우를 실행할 때
- 불안정한 테스트의 근본 원인을 진단하고 수정할 때
- 새 기능에 대한 테스트를 작성할 때
사용 예시
"이 모듈의 테스트 전략을 수립해줘"
"tdd로 비밀번호 검증을 구현해줘" # 매직 키워드로 TDD 모드 활성화
"이 flaky 테스트를 수정해줘"테스팅 피라미드
Test Engineer는 테스팅 피라미드 원칙을 따릅니다.
| 층위 | 비율 | 설명 |
|---|---|---|
| Unit | 70% | 개별 함수/모듈의 동작 검증 |
| Integration | 20% | 컴포넌트 간 상호작용 검증 |
| E2E | 10% | 전체 시스템 동작 검증 |
TDD 프로세스 (Iron Law)
프로덕션 코드 전에 실패하는 테스트가 먼저 있어야 합니다.
- RED: 다음 기능에 대한 테스트 작성. 실행 -- 반드시 실패해야 합니다. 통과하면 테스트가 잘못된 것입니다
- GREEN: 테스트를 통과하기 위한 최소한의 코드만 작성합니다. 추가 기능 금지. 실행 -- 반드시 통과해야 합니다
- REFACTOR: 코드 품질을 개선합니다. 변경할 때마다 테스트를 실행합니다. 그린 유지
- REPEAT: 다음 실패하는 테스트로 반복합니다
코드를 먼저 작성했다면? 삭제하고 테스트부터 다시 시작합니다.
Flaky 테스트 진단
불안정한 테스트의 일반적인 원인과 수정:
| 원인 | 수정 |
|---|---|
| 타이밍 의존성 | waitFor 사용, 하드코딩된 sleep 제거 |
| 공유 상태 | beforeEach에서 상태 초기화 |
| 하드코딩된 날짜 | 상대 날짜 사용 |
| 환경 의존성 | 컨테이너/목(mock) 사용 |
다른 에이전트와의 조합
- executor: 기능 구현은 executor, 테스트 작성은 test-engineer 몫입니다
- verifier: 테스트 적절성 평가와 검증은 verifier에 맡깁니다
- debugger: 테스트 실패의 근본 원인 분석은 debugger와 협력합니다
레퍼런스
| 항목 | 값 |
|---|---|
| 모델 | sonnet |
| 서브에이전트 타입 | oh-my-claudecode:test-engineer |
| 레인 | Domain |
| 이전 이름 | tdd-guide (deprecated) |
| 매직 키워드 | tdd, test first, red green |