초보자가 가장 흔히 틀리는 셀렉터는 무엇인가요?

자동 생성 클래스명·DOM 깊이에 의존한 selector입니다. data-* 속성이나 role 기반 쿼리로 의미를 고정하세요.

should('be.visible')가 느리게 실패해요.

요소는 있지만 z-index, overflow, 애니메이션, 모달 뒤에 가려진 경우가 많습니다. 실제로 클릭 가능한지, 스크롤/포커스가 맞는지 확인하세요.

fixture와 fixture 폴더는 어떻게 나누나요?

정적 JSON은 fixture로 두고, 환경별로는 환경 변수나 cy.intercept로 응답을 바꿉니다. 하드코딩된 production URL은 피합니다.

E2E만으로 품질을 담보할 수 있나요?

E2E는 핵심 시나리오·회귀용이지 전부를 대체하긴 어렵습니다. API·단위와 역할을 나누는 것이 실무에서 더 안정적입니다.

Cypress E2E 테스팅 완벽 가이드 | 자동화·API 모킹·CI/CD·Best Practices

2026년 4월 7일 · 4분 읽기 · 수정 2026년 4월 18일 중급

이 글의 핵심

Cypress로 E2E 테스트를 구축하는 완벽 가이드. 설치, 테스트 작성, 셀렉터, API 모킹, CI/CD 통합, Best Practices까지 실전 예제로 정리. Cypress·E2E Testing·Testing 중심으로 설명합니다.

이 글의 핵심

Cypress로 E2E 테스트를 구축하는 완벽 가이드입니다. 설치부터 테스트 작성, 셀렉터, API 모킹, CI/CD 통합, Best Practices까지 실전 예제로 정리했습니다.

실무 경험 공유: 수동 QA를 Cypress로 자동화하면서, 테스트 시간을 2시간에서 10분으로 단축하고 버그 발견율을 3배 높인 경험을 공유합니다.

들어가며: “수동 테스트가 너무 오래 걸려요”

실무 문제 시나리오

시나리오 1: 매번 수동으로 클릭해야 해요

회귀 테스트에 2시간 걸립니다. Cypress는 10분입니다. 시나리오 2: 브라우저 호환성 테스트가 어려워요

Chrome, Firefox, Safari를 일일이 테스트합니다. Cypress는 자동화합니다. 시나리오 3: 버그를 놓쳐요

사람이 테스트하면 실수가 있습니다. Cypress는 일관성 있게 테스트합니다.

1. Cypress란?

핵심 특징

Cypress는 현대적인 E2E 테스팅 프레임워크입니다. 주요 장점:

빠른 실행: Selenium보다 빠름
자동 대기: 요소가 나타날 때까지 대기
Time Travel: 각 단계 확인
실시간 리로드: 코드 변경 즉시 반영
스크린샷/비디오: 자동 캡처

2. 설치

npm install -D cypress

// package.json
{
  "scripts": {
    "cy:open": "cypress open",
    "cy:run": "cypress run"
  }
}

# GUI 모드
npm run cy:open
# Headless 모드
npm run cy:run

3. 첫 번째 테스트

// cypress/e2e/login.cy.ts
describe('Login', () => {
  beforeEach(() => {
    cy.visit('http://localhost:3000/login');
  });
  it('should login successfully', () => {
    cy.get('[data-testid="email"]').type('[email protected]');
    cy.get('[data-testid="password"]').type('password123');
    cy.get('[data-testid="submit"]').click();
    cy.url().should('include', '/dashboard');
    cy.contains('Welcome back').should('be.visible');
  });
  it('should show error for invalid credentials', () => {
    cy.get('[data-testid="email"]').type('[email protected]');
    cy.get('[data-testid="password"]').type('wrongpassword');
    cy.get('[data-testid="submit"]').click();
    cy.contains('Invalid credentials').should('be.visible');
  });
});

4. 셀렉터

Best Practices

// ❌ 나쁜 예 (변경에 취약)
cy.get('.btn-primary')
cy.get('#submit-button')
cy.get('button:nth-child(2)')
// ✅ 좋은 예 (안정적)
cy.get('[data-testid="submit"]')
cy.get('[data-cy="submit"]')
cy.contains('Submit')

커스텀 명령어

// cypress/support/commands.ts
Cypress.Commands.add('login', (email: string, password: string) => {
  cy.visit('/login');
  cy.get('[data-testid="email"]').type(email);
  cy.get('[data-testid="password"]').type(password);
  cy.get('[data-testid="submit"]').click();
});
// 사용
cy.login('[email protected]', 'password123');

5. API 모킹

cy.intercept

describe('Posts', () => {
  beforeEach(() => {
    cy.intercept('GET', '/api/posts', {
      statusCode: 200,
      body: [
        { id: 1, title: 'Post 1', content: 'Content 1' },
        { id: 2, title: 'Post 2', content: 'Content 2' },
      ],
    }).as('getPosts');
    cy.visit('/posts');
  });
  it('should display posts', () => {
    cy.wait('@getPosts');
    cy.contains('Post 1').should('be.visible');
    cy.contains('Post 2').should('be.visible');
  });
});

Fixture

// cypress/fixtures/users.json
[
  { "id": 1, "name": "John", "email": "[email protected]" },
  { "id": 2, "name": "Jane", "email": "[email protected]" }
]

cy.intercept('GET', '/api/users', { fixture: 'users.json' }).as('getUsers');

6. 인증

세션 저장

// cypress/support/commands.ts
Cypress.Commands.add('loginByApi', (email: string, password: string) => {
  cy.request('POST', 'http://localhost:8000/api/login', {
    email,
    password,
  }).then((response) => {
    window.localStorage.setItem('token', response.body.token);
  });
});
// 사용
beforeEach(() => {
  cy.loginByApi('[email protected]', 'password123');
  cy.visit('/dashboard');
});

7. CI/CD 통합

GitHub Actions

# .github/workflows/cypress.yml
name: Cypress Tests
on: [push, pull_request]
jobs:
  cypress:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Install dependencies
        run: npm ci
      - name: Start server
        run: npm start &
      - name: Wait for server
        run: npx wait-on http://localhost:3000
      - name: Run Cypress tests
        uses: cypress-io/github-action@v6
        with:
          browser: chrome
          record: true
        env:
          CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}
      - name: Upload screenshots
        if: failure()
        uses: actions/upload-artifact@v4
        with:
          name: cypress-screenshots
          path: cypress/screenshots

8. Best Practices

1. 독립적인 테스트

// ❌ 나쁜 예 (의존성 있음)
it('should create user', () => {
  cy.get('[data-testid="name"]').type('John');
  cy.get('[data-testid="submit"]').click();
});
it('should edit user', () => {
  // 이전 테스트에 의존
  cy.contains('John').click();
});
// ✅ 좋은 예 (독립적)
it('should edit user', () => {
  cy.loginByApi('[email protected]', 'password123');
  cy.visit('/users/1');
  cy.contains('Edit').click();
});

2. data-testid 사용

<!-- HTML -->
<button data-testid="submit-button">Submit</button>

// Test
cy.get('[data-testid="submit-button"]').click();

3. 명시적 대기

// ❌ 나쁜 예
cy.wait(5000);
// ✅ 좋은 예
cy.get('[data-testid="loading"]').should('not.exist');
cy.get('[data-testid="content"]').should('be.visible');

심화: Cypress 아키텍처·intercept·커버리지·프로덕션

인-브라우저 실행 모델

Cypress는 전통적인 원격 WebDriver와 달리, 애플리케이션과 테스트 제어를 브라우저 이벤트 루프에 가깝게 맞추는 방향으로 설계되어 왔습니다(세부 구현은 버전별로 문서를 확인). 실무적으로는 명령 큐와 자동 재시도 덕분에 단언이 안정적으로 붙는 경우가 많지만, 순수 Promise와 커맨드를 섞는 안티패턴은 플레이크를 유발합니다.

`cy.intercept`와 네트워크 스텁

cy.intercept는 XHR/fetch 경로를 가로채 고정 응답·지연·에러를 시뮬레이션합니다. as('alias')와 cy.wait('@alias')로 네트워크 동기화를 하면 cy.wait(5000) 같은 고정 대기보다 안정적입니다.

커버리지

Cypress로 프런트 계측 커버리지를 모으는 구성도 가능하지만, 일반적으로 Vitest/Jest에서 임계값을 관리하고 E2E는 핵심 여정 검증에 두는 편이 비용 대비 효과가 좋습니다.

프로덕션

E2E 스위트는 스테이징·프리뷰가 기본이며, 프로덕션에는 합성 헬스 체크와 관측(RUM·APM) 으로 보완합니다. 영문 심화 요약은 [Cypress E2E Testing Guide (English)](/en/blog/cypress-e2e-testing-guide/를 참고하십시오.

정리 및 체크리스트

핵심 요약

Cypress: 현대적인 E2E 테스팅
자동 대기: 요소가 나타날 때까지
API 모킹: cy.intercept
Time Travel: 각 단계 확인
CI/CD: GitHub Actions 통합
Best Practices: 독립적 테스트

구현 체크리스트

같이 보면 좋은 글

[Cypress E2E Testing Guide (English)](/en/blog/cypress-e2e-testing-guide/
Playwright E2E 테스팅 가이드
Vitest 완벽 가이드
GitHub Actions CI/CD 가이드

이 글에서 다루는 키워드

Cypress, E2E Testing, Testing, Automation, CI/CD, Quality Assurance

자주 묻는 질문 (FAQ)

Q. Cypress vs Playwright, 어떤 게 나은가요?

A. Cypress가 더 사용하기 쉽습니다. Playwright가 더 빠르고 기능이 많습니다. 초보자는 Cypress, 고급 사용자는 Playwright를 권장합니다.

Q. 유닛 테스트도 Cypress로 하나요?

A. 아니요, E2E 테스트만 Cypress를 사용하세요. 유닛 테스트는 Vitest나 Jest를 사용하세요.

Q. 실제 API를 호출해야 하나요?

A. 아니요, cy.intercept로 모킹하는 것을 권장합니다. 더 빠르고 안정적입니다.

Q. 프로덕션에서 사용해도 되나요?

A. 네, 많은 기업에서 프로덕션 배포 전 E2E 테스트로 사용합니다.

심화 부록: 구현·운영 관점

이 부록은 앞선 본문에서 다룬 주제(「Cypress E2E 테스팅 완벽 가이드 | 자동화·API 모킹·CI/CD·Best Practices」)를 구현·런타임·운영 관점에서 다시 압축합니다. 도메인별 세부 구현은 글마다 다르지만, 입력 검증 → 핵심 연산 → 부작용(I/O·네트워크·동시성) → 관측의 흐름으로 장애를 나누면 원인 추적이 빨라집니다.

내부 동작과 핵심 메커니즘

flowchart TD
  A[입력·요청·이벤트] --> B[파싱·검증·디코딩]
  B --> C[핵심 연산·상태 전이]
  C --> D[부작용: I/O·네트워크·동시성]
  D --> E[결과·관측·저장]

sequenceDiagram
  participant C as 클라이언트/호출자
  participant B as 경계(런타임·게이트웨이·프로세스)
  participant D as 의존성(API·DB·큐·파일)
  C->>B: 요청/이벤트
  B->>D: 조회·쓰기·RPC
  D-->>B: 지연·부분 실패·재시도 가능
  B-->>C: 응답 또는 오류(코드·상관 ID)

불변 조건(Invariant): 버퍼 경계, 프로토콜 상태, 트랜잭션 격리, FD 상한 등 단계별로 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
결정성: 순수 층과 시간·네트워크·스케줄에 의존하는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
경계 비용: 직렬화, 인코딩, syscall 횟수, 락 경합, 할당·GC, 캐시 미스를 의심 목록에 둡니다.
백프레셔: 생산자가 소비자보다 빠를 때 버퍼·큐·스트림에서 속도를 줄이는 신호를 어디에 둘지 정의합니다.

프로덕션 운영 패턴

영역	운영 관점 질문
관측성	요청 단위 상관 ID, 에러율·지연 p95/p99, 의존성 타임아웃·재시도가 대시보드에 보이는가
안전성	입력 검증·권한·비밀·감사 로그가 코드 경로마다 일관적인가
신뢰성	재시도는 멱등 연산에만 적용되는가, 서킷 브레이커·백오프·DLQ가 있는가
성능	캐시·배치 크기·커넥션 풀·인덱스·백프레셔가 데이터 규모에 맞는가
배포	롤백 룬북, 카나리/블루그린, 마이그레이션·피처 플래그가 문서화되어 있는가
용량	피크 트래픽·디스크·FD·스레드 풀 상한을 주기적으로 검증하는가

스테이징은 데이터 양·네트워크 RTT·동시성을 프로덕션에 가깝게 맞출수록 재현율이 올라갑니다.

확장 예시: 엔드투엔드 미니 시나리오

앞선 본문 주제(「Cypress E2E 테스팅 완벽 가이드 | 자동화·API 모킹·CI/CD·Best Practices」)를 배포·운영 흐름에 맞춰 옮긴 체크리스트입니다. 도메인에 맞게 단계 이름만 바꿔 적용할 수 있습니다.

입력 계약 고정: 스키마·버전·최대 페이로드·타임아웃·에러 코드를 경계에 둔다.
핵심 경로 계측: 요청 ID, 단계별 지연, 외부 호출 결과 코드를 로그·메트릭·트레이스에서 한 흐름으로 본다.
실패 주입: 의존성 타임아웃·5xx·부분 데이터·락 대기를 스테이징에서 재현한다.
호환·롤백: 설정/마이그레이션/클라이언트 버전을 되돌릴 수 있는지 확인한다.
부하 후 검증: 피크 대비 p95/p99, 에러율, 리소스 상한, 알림 임계값을 점검한다.

handle(request):
  ctx = newCorrelationId()
  validated = validateSchema(request)
  authorize(validated, ctx)
  result = domainCore(validated)
  persistOrEmit(result, idempotentKey)
  recordMetrics(ctx, latency, outcome)
  return result

문제 해결(Troubleshooting)

증상	가능 원인	조치
간헐적 실패	레이스, 타임아웃, 외부 의존성, DNS	최소 재현 스크립트, 분산 트레이스·로그 상관관계, 재시도·서킷 설정 점검
성능 저하	N+1, 동기 I/O, 락 경합, 과도한 직렬화, 캐시 미스	프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거
메모리 증가	캐시 무제한, 구독/리스너 누수, 대용량 버퍼, 커넥션 미반납	상한·TTL·힙/FD 스냅샷 비교
빌드·배포만 실패	환경 변수, 권한, 플랫폼 차이, lockfile	CI 로그와 로컬 diff, 런타임·이미지 버전 핀
설정 불일치	프로필·시크릿·기본값, 리전	스키마 검증된 설정 단일 소스와 배포 매트릭스 표준화
데이터 불일치	비멱등 재시도, 부분 쓰기, 캐시 무효화 누락	멱등 키·아웃박스·트랜잭션 경계 재검토

권장 순서: (1) 최소 재현 (2) 최근 변경 범위 축소 (3) 환경·의존성 차이 (4) 관측으로 가설 검증 (5) 수정 후 회귀·부하 테스트.

배포 전에는 git add → git commit → git push 후 npm run deploy 순서를 권장합니다.

이 글이 도움이 되셨나요?

여러분의 피드백은 더 나은 콘텐츠를 만드는 데 도움이 됩니다

문제가 있거나 개선 제안이 있으시면 연락처로 알려주세요.

Keyboard Shortcuts

이 글의 핵심

이 글의 핵심

들어가며: “수동 테스트가 너무 오래 걸려요”

실무 문제 시나리오

사람이 테스트하면 실수가 있습니다. Cypress는 일관성 있게 테스트합니다.

1. Cypress란?

핵심 특징

2. 설치

3. 첫 번째 테스트

4. 셀렉터

Best Practices

커스텀 명령어

5. API 모킹

cy.intercept

Fixture

6. 인증

세션 저장

7. CI/CD 통합

GitHub Actions

8. Best Practices

1. 독립적인 테스트

2. data-testid 사용

3. 명시적 대기

심화: Cypress 아키텍처·intercept·커버리지·프로덕션

인-브라우저 실행 모델

cy.intercept와 네트워크 스텁

커버리지

프로덕션

정리 및 체크리스트

핵심 요약

구현 체크리스트

같이 보면 좋은 글

이 글에서 다루는 키워드

자주 묻는 질문 (FAQ)

Q. Cypress vs Playwright, 어떤 게 나은가요?

Q. 유닛 테스트도 Cypress로 하나요?

Q. 실제 API를 호출해야 하나요?

Q. 프로덕션에서 사용해도 되나요?

심화 부록: 구현·운영 관점

내부 동작과 핵심 메커니즘

프로덕션 운영 패턴

확장 예시: 엔드투엔드 미니 시나리오

문제 해결(Troubleshooting)

이 글이 도움이 되셨나요?

`cy.intercept`와 네트워크 스텁