쉽고 편리한 E2E 테스트 자동화를 꿈꾸며...

1. Playwright를 선택하는 이유

Playwright는 Chromium·Firefox·WebKit을 단일 API로 테스트할 수 있고, 기본적으로 요소가 준비될 때까지 기다리는 auto-wait 기능이 있어 `sleep()` 없이 안정적인 테스트를 작성할 수 있습니다. `getByRole`, `getByText`, `getByTestId` 같은 사용자 관점의 선택자를 권장해 리팩터링에도 강건합니다.

핵심 용어

2. Page Object Model(POM) 패턴

페이지별로 클래스를 만들어 UI 선택자와 액션을 캡슐화합니다. 테스트 코드에서 직접 선택자를 쓰지 않고 POM 메서드를 호출합니다. UI가 바뀌면 POM 클래스만 수정하면 되므로 유지보수 비용이 크게 줄어듭니다.

핵심 용어

3. Flaky 테스트 줄이기

Flaky 테스트(실행마다 결과가 다른 테스트)의 주요 원인은 타이밍 의존성, 테스트 간 상태 공유, 외부 API 의존입니다. 해결책: auto-wait 활용, 테스트마다 독립 데이터 사용, API 모킹(Playwright의 route()). 병렬 실행 시 DB 충돌을 방지하려면 테스트별 격리 환경이 필요합니다.

핵심 용어

Q1. E2E 테스트와 단위 테스트, 통합 테스트의 차이를 설명하고 언제 E2E가 필요한지 말씀해주세요.

힌트

[감점 답변] 정의만 반복하거나 "E2E 테스트와 단위 테스트, 통합 테스트의 차이를 설명하고 언제 E2E가 필요한지 말씀해주세요."에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] 테스트 피라미드로 설명하세요. 단위: 함수 하나의 순수 로직. 통합: 여러 모듈의 상호작용. E2E: 실제 브라우저에서 사용자 시나리오 전체를 검증. E2E는 느리고 비용이 크지만 '배포 직전 핵심 시나리오가 동작하는가'를 보장하는 마지막 안전망입니다.

Q2. Playwright에서 테스트 선택자를 어떻게 작성하는 것이 좋은가요?

힌트

[감점 답변] 정의만 반복하거나 "Playwright에서 테스트 선택자를 어떻게 작성하는 것이 좋은가요?"에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] 우선순위: getByRole > getByLabelText > getByText > getByTestId > CSS selector. 사용자가 실제로 인식하는 방식(역할, 레이블)으로 선택하면 리팩터링에 강건합니다. data-testid는 의미론적이지 않지만 다른 방법이 없을 때 사용합니다. CSS class나 XPath는 구현 세부사항에 의존하므로 최후 수단입니다.

Q3. CI에서 E2E 테스트가 불안정하게 실패할 때 어떻게 디버깅하나요?

힌트

[감점 답변] 정의만 반복하거나 "CI에서 E2E 테스트가 불안정하게 실패할 때 어떻게 디버깅하나요?"에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] Playwright의 trace viewer(`--trace on`)를 활용하면 실패 시 스크린샷, 네트워크 요청, 콘솔 로그를 타임라인으로 확인할 수 있습니다. CI 환경에서 `--headed` 대신 `--reporter=html`로 리포트를 저장하고 아티팩트로 업로드하면 원인 파악이 쉬워집니다.