이전 글에서 Vitest를 도입해 유틸 함수 단위 테스트 환경을 구축했습니다.
이를 통해 전역적으로 사용하는 util 함수에 대한 검증을 마칠 수 있었습니다.
하지만 실제 프로젝트를 운영하면서 몇 가지 아쉬움이 있었습니다.
Chrome 외 브라우저 환경은 직접 확인해야 했고, 단위 테스트만으로는 실제 UI가 어떻게 동작하는지까지 검증하기 어려웠습니다.
오토위니 Keycloak 테마 프로젝트에서 Storybook을 활용해 UI를 검증해 본 경험은 있었습니다.
하지만 이번에는 단순히 컴포넌트를 확인하는 수준을 넘어, 실제 브라우저 환경에서 사용자 흐름까지 검증할 수 있는 테스트가 필요했습니다.
크로스 브라우징 테스트가 가능하고, 실제 UI 동작을 확인할 수 있으며, 비교적 간편하게 도입할 수 있는 도구를 찾고 있었습니다.
이러한 조건을 고려했을 때, 평소 실무에서 많이 사용된다고 들었던 Playwright를 이번 프로젝트에 도입해 보기로 했습니다.
테스트 도입 방식
초기 테스트 코드는 Claude Code를 활용해 작성했습니다.
기존 코드를 기반으로 Playwright 테스트 코드를 생성하도록 했으며, 문법도 Vitest와 크게 다르지 않아 빠르게 적응할 수 있었습니다.
처음에는 "현재 코드를 기반으로 테스트 코드를 작성해달라"는 방식으로 기본 테스트를 구성했고, 이후에는 테스트가 자연스럽게 누적될 수 있도록 규칙 기반으로 관리하는 방향으로 확장했습니다.
테스트 파일 구조
현재 E2E 테스트는 e2e/ 디렉토리 하위에서 페이지(도메인) 단위로 분리하여 관리하고 있습니다.
- 페이지별 *.spec.ts
- 공통 데이터: fixtures/
- 공통 로직 및 mocking: helpers/
기존 도메인 중심 구조를 그대로 유지하면서 테스트 코드 역시 동일한 기준으로 분리했습니다.
Claude Code를 활용한 테스트 자동화
테스트 코드가 일관되게 작성될 수 있도록 CLAUDE.md에 규칙을 정의해 자동화 흐름을 구성했습니다.
CLAUDE.md
새 페이지나 도메인 기능을 추가/수정할 때는 반드시 `e2e/` 폴더에 Playwright 테스트를 추가한다.
- 테스트 파일 위치: `e2e/<도메인명>.spec.ts`
- API 응답은 `page.route()`로 모킹 — 실제 백엔드에 의존하지 않음
- `recommended-keywords` 엔드포인트는 응답 body를 `[]`로 반환
- 공통 mock 헬퍼는 `e2e/helpers/mockApi.ts` 참고
- 번역 키는 실제 locale 값을 기준으로 검증
- URL 파라미터 검증 시 상수 값 확인 (`sorting`)
이 설정을 통해 기능 개발 시 Claude Code가 기존 코드를 분석하고, Playwright 테스트 코드를 자동으로 생성하도록 구성했습니다.
결과적으로 테스트를 "작성하는 작업"이 아니라, 검토하고 실행하는 과정으로 전환할 수 있었습니다.
크로스 브라우징 테스트 화면
개별 UI 테스트 화면
느낀 점
이번에는 기존 코드베이스를 기반으로 테스트 코드를 작성했지만, 앞으로는 새롭게 개발되는 기능에 대해서는 CLAUDE.md에 정의한 규칙을 기반으로 Claude Code가 테스트 코드를 자동으로 생성하도록 구성했습니다.
또한 앞으로는 기획서와 요구사항을 기반으로 테스트를 검증하는 방향으로 확장할 예정이기 때문에, 점차 QA 자동화와 개발 효율 측면에서 긍정적인 효과를 기대할 수 있을 것이라 생각합니다.