Cypress 모범 사례 — 규모에 맞게 확장되는 테스트
Cypress 모범 사례 — 규모에 맞게 확장되는 테스트
테스트 개수가 늘어나면 "어떻게 하면 흔들리지 않는 테스트를 유지할까" 고민이 생겨요. Cypress 팀은 테스트를 어떻게 구성하고, 로그인을 어떻게 처리하고, 상태를 어떻게 제어할지에 대한 모범 사례를 정리해 두었어요. 셀렉터 선정과 반환값 처리 전략부터 외부 사이트 방문, 이전 테스트 상태 의존 회피까지, 확장 가능한 테스트의 원칙을 담고 있어요.
민감한 값 처리 — API에 맞는 사용
테스트를 쓰다 보면 API 키, 비밀번호, 토큰, DB 자격증명 같은 민감한 데이터를 다뤄야 할 때가 많아요. Cypress는 각각 다른 보안 특성과 용도를 가진 세 가지 설정 값 API를 제공해요.
- 안티 패턴: 테스트 파일에 시크릿을 하드코딩하거나,
Cypress.expose()를 민감한 값에 쓰거나, 시크릿을 브라우저 컨텍스트에 노출하는 것 - 모범 사례: 용도에 맞는 API를 쓰는 것 — 테스트의 민감한 값은
cy.env()로, 공개 설정에만Cypress.expose()를 사용
baseUrl을 설정하면 cypress open 시 그 주소에서 서버가 뜨지 않았을 때 오류를 보여 주고, cypress run에서도 여러 번 재시도 후 서버가 실행 중인지 확인해 주는 부가 이점이 있어요.
실용적인 확장 전략
확장 가능한 테스트의 핵심 원칙은 이 정도로 정리할 수 있어요.
- 테스트를 독립적으로 만들고 이전 테스트의 상태(state)에 의존하지 않기
- 후크(hook)는 목적에 맞게 선택 — 상태 정리는
after/afterEach를 필요한 순간에만 - 불필요한 대기(waiting) 피하기 — Cypress는 커맨드가 요소를 찾을 때까지 자동으로 재시도(
retry-ability)하므로 임의의cy.wait()은 흔들림을 만듦 - 셀렉터는 안정적으로 — 텍스트나 CSS 클래스 대신 데이터 속성처럼 앱 로직과 결합이 약한 셀렉터를 선호
baseUrl을 설정해 매 테스트마다 전체 URL을 반복하지 않기
Cypress 팀이 운영하는 Real World App(RWA)은 이런 모범 사례를 실제 시나리오에서 보여 주는 풀스택 예제 앱이에요. E2E 테스트만으로 완전한 코드 커버리지를 달성하고, 다중 브라우저·기기 크기·시각적 회귀 테스트·API 테스트·유닛 테스트를 함께 돌리는 CI 파이프라인을 갖추고 있어요. 저장소를 클론하면 바로 테스트를 시작할 수 있어요.
정리하면, Cypress 테스트를 확장해 갈 때는 독립성, 안정적 셀렉터, 불필요한 대기 지양, 올바른 상태 제어가 핵심이에요. 민감한 값은 반드시 알맞은 API(cy.env())로 다루고, RWA 같은 실제 예제를 참고하면 좋아요.