Cypress E2E 테스트 전략 가이드

Cypress의 가치는 브라우저를 움직일 수 있다는 사실보다, **정말 브라우저 수준 증명이 필요한 사용자 여정을 신뢰 가능하게 검증할 수 있다는 점**에 있습니다. 반대로 싼 계층에서 검증했어야 할 문제까지 모두 떠안기 시작하면 E2E는 가장 비싸고 가장 flaky한 계층이 됩니다.

그래서 좋은 Cypress 전략은 범위 통제와 테스트 데이터 규율, flaky 감소 설계에 달려 있습니다.

E2E는 핵심 사용자 흐름만 맡겨야 합니다

Cypress가 특히 잘 맞는 대상은 다음과 같습니다.

• 인증과 세션이 중요한 흐름
• 결제와 체크아웃
• 권한이 민감한 사용자 작업
• 실제 브라우저 증명이 꼭 필요한 핵심 제품 여정

반대로 작은 시각 차이, 자잘한 validation 분기, 값싼 하위 계층에서 충분히 증명 가능한 동작까지 E2E로 올리는 것은 좋은 전략이 아닙니다.

Selector 전략은 오래 버틸 수 있어야 합니다

Cypress를 brittle하게 만드는 가장 쉬운 방법 중 하나는 우연한 DOM 구조에 강하게 묶는 것입니다.

더 안정적인 선택은 보통 다음입니다.

• 접근성 의미가 있는 경우 role 기반 selector
• 테스트 타깃을 위한 data-testid 같은 전용 속성
• 깊은 CSS 경로 의존 피하기

좋은 selector는 스타일 우연이 아니라 사용자 의도나 안정적인 계약을 표현해야 합니다.

시간 대신 조건을 기다려야 합니다

임의의 sleep은 flaky E2E를 만드는 가장 빠른 길입니다.

더 건강한 방식은 다음 조건을 기다리는 것입니다.

• 눈에 보이는 UI 상태 변화
• network alias 완료
• URL 변화
• 도메인적으로 의미 있는 완료 신호

조건 기반 대기는 CI 환경에서도 더 결정적이고 디버깅도 쉽습니다.

네트워크 제어는 의도적으로 해야 합니다

Cypress는 어떤 의존성을 실제로 붙이고, 어떤 의존성을 통제할지 분명할수록 훨씬 안정적입니다.

유용한 패턴은 다음과 같습니다.

• 불안정한 서드파티 API는 stub 처리
• 알려진 시나리오는 fixture로 응답 고정
• 중요한 결과는 intercept로 검증
• 전체 스택 증명이 정말 필요한 흐름만 실제 서비스와 연결

이렇게 해야 E2E가 맡아야 할 신뢰도를 정확히 제공할 수 있습니다.

테스트 데이터 소유권이 중요합니다

많은 flaky Cypress 스위트는 사실 브라우저 문제가 아니라 테스트 데이터 문제입니다.

팀은 최소한 다음을 정해야 합니다.

• 테스트 사용자와 seed data를 어떻게 만들 것인가
• 테스트 간 상태를 어떻게 격리할 것인가
• 테스트가 독립 실행 가능한가
• CI에서 reset 또는 cleanup을 어떻게 할 것인가

데이터가 느슨하게 공유되면 실패는 시끄럽고 원인 추적은 어려워집니다.

디버깅 가능성도 설계 대상입니다

Cypress의 장점은 실패가 시각적으로 남고 추적하기 쉽다는 점입니다. 이 장점을 유지하려면 시나리오를 다음처럼 관리하는 편이 좋습니다.

• 빠르게 이해할 수 있을 만큼 짧게
• 비즈니스 여정 기준으로 이름 짓기
• setup과 assertion을 명시적으로 유지

한 시나리오에서 너무 많은 것을 증명하려는 거대한 스크립트는 실패 원인 파악이 훨씬 어렵습니다.

흔한 안티패턴

실무에서는 다음 패턴이 자주 E2E 품질을 떨어뜨립니다.

• 작은 UI 디테일까지 E2E에서 검증
• random sleep으로 flaky를 덮음
• selector 규율이 약함
• 테스트 간 상태를 공유
• 한 시나리오에 너무 많은 외부 시스템 의존을 넣음

이런 구조가 Cypress를 느리고 믿기 어려운 도구로 만듭니다.

리뷰 체크리스트

Cypress 스위트가 건강한지 보려면 다음을 물어야 합니다.

• 이 흐름이 정말 브라우저 수준 증명이 필요한가
• selector가 안정적이고 의도가 드러나는가
• 시간 대신 실제 조건을 기다리는가
• 테스트 데이터가 격리되고 소유되고 있는가
• 실패했을 때 원인을 빠르게 좁힐 수 있는가

마무리

Cypress는 정말 브라우저에서 먼저 깨져야 하는 여정만 남길 때 가장 가치가 큽니다. 나머지는 더 싼 계층으로 내리고, E2E에는 사용자 여정의 최종 증명만 맡기는 것이 좋은 전략입니다.

Continue Reading

다음으로 읽기 좋은 글

🧪 Test

Playwright로 크로스 브라우저 E2E 테스트하기

Playwright를 단순 브라우저 자동화 도구가 아니라 신뢰 가능한 E2E 테스트 플랫폼으로 활용하는 방법을 정리합니다. 전략, 설정, selector 규칙, mocking, 인증 상태 재사용, flaky 감소 방법까지 다룹니다.

🧪 Test

Jest로 JavaScript 단위 테스트 작성하기

Jest 문법 소개를 넘어서 무엇을 단위 테스트해야 하는지, Mock를 어디까지 써야 하는지, 유지보수 가능한 테스트 기준을 실무 관점에서 정리합니다.

💬 Language

TypeScript Utility Types 실전 가이드

TypeScript 유틸리티 타입을 DTO, 업데이트 payload, selector, 파생 타입 설계에 어떻게 써야 하는지, 어디서부터는 가독성을 해치는지 정리합니다.

💬 Language

Modern JavaScript ES2024 문법 실전 해설

최신 JavaScript 문법을 단순 문법 소개가 아니라, 코드 품질을 실제로 높이는지 기준으로 읽습니다. 무엇이 진짜 도움이 되고 무엇은 여전히 절제가 필요한지 정리합니다.