전체 목록
테스트Hard#440

E2E 테스트가 flaky해지는 주요 원인과 줄이는 방법을 설명해주세요.

#테스트#E2E#FlakyTest#품질

답변 포인트

비동기 UI, 네트워크, 시간 의존성, 테스트 간 공유 상태를 기준으로 생각해보세요.

정답 및 해설

빠른 요약

Flaky 테스트는 코드가 바뀌지 않았는데도 어떤 때는 통과하고 어떤 때는 실패하는 테스트입니다. E2E 테스트는 실제 브라우저, 네트워크, 서버, DB를 함께 다루기 때문에 flaky해지기 쉽습니다.

Flaky 테스트는 코드가 바뀌지 않았는데도 어떤 때는 통과하고 어떤 때는 실패하는 테스트입니다. E2E 테스트는 실제 브라우저, 네트워크, 서버, DB를 함께 다루기 때문에 flaky해지기 쉽습니다.

주요 원인은 다음과 같습니다.

  • 고정 sleep에 의존하는 대기
  • API 응답 시간이나 애니메이션 타이밍 변동
  • 테스트 간 사용자 계정, DB 데이터 공유
  • 외부 서비스 의존
  • 현재 시간, timezone, 랜덤 값 영향
  • 선택자가 UI 문구나 CSS 구조에 너무 민감함

개선 방법은 “기다림을 명시적 조건으로 바꾸는 것”에서 시작합니다. waitForTimeout(3000)보다 “버튼이 enabled 될 때까지”, “응답이 완료될 때까지” 기다리는 편이 안정적입니다.

테스트 데이터는 매번 독립적으로 만들고 정리해야 합니다. 가능하면 테스트 전용 계정, 전용 DB schema, API mocking을 사용합니다. 선택자는 data-testid처럼 의도를 담은 안정적인 값을 쓰는 것이 좋습니다.

또한 모든 것을 E2E로 검증하려고 하면 느리고 불안정해집니다. 핵심 사용자 플로우만 E2E로 두고, 복잡한 분기 로직은 unit/integration 테스트로 내리는 테스트 피라미드 전략이 필요합니다.

관련 질문

같은 카테고리/태그 기준