Claude Code로 테스트 자동화하는 방법 2026

Claude Code로 테스트를 작성할 때 단순히 "테스트 짜줘"가 아니라 엣지케이스와 실패 시나리오를 명시하면 커버리지가 30-50% 더 높아집니다. 이 가이드는 단위 테스트부터 E2E까지 실전 패턴을 정리합니다.

기본 테스트 생성

단위 테스트

/add src/utils/price-calculator.ts

"이 함수의 테스트를 작성해줘:
- 정상 케이스 (할인 있음/없음)
- 경계값 (0원, 음수, 최대값)
- 에러 케이스 (잘못된 입력)
- 부동소수점 오차 케이스
Vitest 사용, describe/it 구조"

기존 코드에 테스트 추가

/add src/auth/jwt.ts
/add src/auth/__tests__/jwt.test.ts  # 있으면 추가

"jwt.ts의 테스트 커버리지를 80% 이상으로 높여줘.
현재 테스트가 없는 케이스:
- 만료된 토큰
- 잘못된 시그니처
- 페이로드 누락
- 알고리즘 불일치
각 케이스에 대한 테스트 추가해줘"

TDD 워크플로우

테스트를 먼저 쓰고 구현을 만드는 패턴:

# 1. 요구사항으로 테스트 먼저
"다음 요구사항의 테스트를 먼저 작성해줘 (구현은 없어도 됨):
- 사용자가 3회 로그인 실패 시 계정 잠금
- 잠금 해제는 이메일 인증으로만 가능
- 잠금 상태에서 로그인 시도 시 남은 잠금 시간 반환
실패하는 테스트로 시작해줘"

# 테스트 실행 → 실패 확인
bun test auth.test.ts

# 2. 테스트가 통과하는 최소 구현
"방금 작성한 테스트를 모두 통과시키는 최소한의 구현을 작성해줘"

# 3. 리팩토링
"테스트가 통과한 상태에서 코드를 정리해줘"

엣지케이스 발견

/add src/payment/processor.ts

"이 결제 처리 코드에서 테스트가 필요한 엣지케이스를 찾아줘:
1. 네트워크 타임아웃
2. 결제사 서버 500 에러
3. 중복 결제 시도 (멱등성)
4. 금액 불일치 (요청 금액 ≠ 실제 청구)
5. 통화 변환 오차
각 케이스의 테스트 코드 작성해줘"

통합 테스트 패턴

// Claude Code로 생성한 통합 테스트 패턴
describe('Order API 통합 테스트', () => {
  let app: FastifyInstance;
  let db: Database;

  beforeAll(async () => {
    db = await createTestDatabase(); // 인메모리 DB
    app = await createApp({ db });
  });

  afterAll(async () => {
    await db.close();
    await app.close();
  });

  afterEach(async () => {
    await db.clear(); // 각 테스트 후 초기화
  });

  it('주문 생성 → 재고 감소 → 이메일 발송 플로우', async () => {
    // Given
    await db.products.insert({ id: 'p1', stock: 10 });
    const emailSpy = jest.spyOn(emailService, 'send');

    // When
    const res = await app.inject({
      method: 'POST',
      url: '/orders',
      payload: { productId: 'p1', quantity: 3, userId: 'u1' }
    });

    // Then
    expect(res.statusCode).toBe(201);
    expect(await db.products.findById('p1')).toMatchObject({ stock: 7 });
    expect(emailSpy).toHaveBeenCalledWith(
      expect.objectContaining({ template: 'order-confirmation' })
    );
  });
});

"위 패턴으로 우리 API의 통합 테스트를 작성해줘.
데이터베이스는 인메모리 SQLite 사용,
외부 API(결제, 이메일)는 mock 처리"

스냅샷 테스트

컴포넌트 UI 회귀 방지:

/add src/components/ProductCard.tsx

"ProductCard 컴포넌트의 스냅샷 테스트 작성해줘:
- 기본 상태
- 할인 가격 표시 상태
- 품절 상태
- 로딩 스켈레톤 상태
React Testing Library 사용"

E2E 테스트 (Playwright)

"주요 사용자 플로우의 Playwright E2E 테스트 작성해줘:
1. 회원가입 → 이메일 인증 → 로그인
2. 상품 검색 → 장바구니 → 결제 (테스트 카드 사용)
3. 주문 취소 → 환불 처리

각 테스트는:
- page fixture 사용
- 테스트 격리 (beforeEach로 초기 상태)
- 실패 시 스크린샷 저장"

커버리지 향상 전략

# 1. 현재 커버리지 확인
bun test --coverage

# 2. 커버리지 낮은 파일 파악 후 Claude Code에 전달
"coverage 리포트에서 커버리지 60% 미만인 파일:
- src/api/webhooks.ts (45%)
- src/utils/date-formatter.ts (52%)
이 파일들의 테스트를 80% 이상으로 높여줘"

Mock과 Spy 패턴

"이 코드의 테스트에서 외부 의존성을 적절히 mock해줘:
- Stripe API → jest.mock 또는 nock
- sendEmail → spy (실제 발송 방지)
- Date.now() → 고정값으로 mock (시간 의존 테스트)
- Redis → ioredis-mock 사용

각 mock의 이유를 주석으로 설명해줘"

실측 데이터

Claude Code 테스트 자동화 실제 결과:

Frequently Asked Questions

Claude Code가 생성한 테스트가 실제로 의미 있나요?

테스트 품질은 프롬프트 품질에 비례합니다. "테스트 짜줘"보다 "만료된 JWT, 잘못된 서명, 알고리즘 불일치 케이스 포함해서 짜줘"처럼 구체적일수록 유의미한 테스트가 나옵니다.

TDD로 시작할 때 테스트가 실패해야 정상인가요?

네. Red → Green → Refactor 사이클에서 테스트는 처음엔 반드시 실패해야 합니다. Claude Code에 "먼저 실패하는 테스트만 작성해줘, 구현은 나중에"라고 명시하면 됩니다.

외부 API 테스트는 실제로 호출해야 하나요?

단위/통합 테스트에서는 mock을 사용합니다. E2E 테스트에서만 실제 환경(또는 sandbox)을 사용하되, 결제 API는 테스트 카드를 사용하세요.

테스트 파일이 너무 많아지면 어떻게 관리하나요?

__tests__ 폴더 또는 .test.ts 파일을 소스 옆에 두는 colocated 방식을 권장합니다. Claude Code에 "기존 프로젝트 파일 구조를 따라서 테스트 파일 위치 결정해줘"라고 하면 일관성을 유지합니다.

관련 가이드: Claude Code CI/CD 가이드 한국어 · Claude Code 완전 가이드 한국어 · Claude Code Hooks 한국어

P1 Claude Code Power Prompts 300 — TDD 및 테스트 자동화 전용 프롬프트 35개 포함. 지금 확인 →