Playwright: 테스트 구조 (작지만 큰 영향을 주는 부분)
Source: Dev.to
소개
Hi there 👋! This is my first post since I joined dev.to.
저는 최근 고객 지원에서 QA로 전환한 주니어 QA 엔지니어입니다. 아직 경험이 많지는 않지만—특히 자동화 테스트를 깊이 있게 논의할 정도는 아니지만—일상 업무에서 한 가지 중요한 점을 발견했습니다:
많은 QA 엔지니어가 자동화 테스트를 작성하지만, 모두가 테스트 구조를 제대로 이해하고 있는 것은 아닙니다. 명확하고 신중하게 설계된 테스트 구조가 없으면 자동화 테스트는 금방:
- 유지 관리가 어려워지고
- 테스트 실패 시 디버깅이 어려워지고
- 제품이 성장함에 따라 확장하기 위험해집니다
종종 간과되는 간단한 개선점은 자동화 테스트를 어떻게 구조화하느냐 입니다. 테스트 구조가 기본적인 것처럼 들리지만, 자동화에 새로 입문했거나 실제 프로젝트 경험이 제한된 많은 QA 엔지니어들은 그 중요성을 충분히 인식하지 못할 수 있습니다.
이번 포스트에서는 지금까지 배운 내용을 바탕으로 테스트 구조 관리에 대한 몇 가지 간단한 팁을 공유하려 합니다. 작은 주제일 수 있지만 큰 영향을 미칩니다.
📂 기본 Playwright 테스트 구조 (시작점)
tests/
├── example.spec.ts
├── another-test.spec.ts
playwright.config.ts이 레이아웃은 데모, 튜토리얼 또는 아주 작은 프로젝트에서는 잘 작동합니다. 하지만 테스트 스위트가 커지면 구조가 금방 문제를 일으키게 됩니다.
기본 구조의 일반적인 문제점
- 테스트 파일마다 선택자가 중복됨
- 테스트가 길어지고 읽기 어려워짐
- UI 변경 시 많은 테스트 파일을 수정해야 함
- 실패한 테스트를 디버깅하는 데 시간이 오래 걸림
그래서 저는 프로젝트 초기에 기본 구조에서 벗어나기로 결정했습니다.
🧱 저장소에서 사용되는 맞춤 테스트 구조
*.spec.ts 파일에 모든 것을 직접 넣는 대신, 관심사를 명확히 분리했습니다.
고수준 구조 (단순화)
tests/
├── pages/
├── fixtures/
├── utils/
├── ai/
│ └── ai-movie.spec.ts📄 1. Page Object Model (POM)
pages/ 폴더에는 다음을 담당하는 페이지 클래스가 포함됩니다:
- selectors
- page actions (click, fill, submit 등)
테스트는 다음과 같은 메서드를 통해 페이지와 상호 작용합니다:
searchMovie()submitPrompt()readAIResponse()
왜 중요한가
- UI 변경이 발생해도 페이지 파일만 수정하면 됩니다
- 테스트 파일은 깔끔하고 가독성이 높아집니다
- selector 중복이 줄어듭니다
기본 Playwright 접근 방식과 비교했을 때, 유지 보수 비용을 크게 줄여줍니다.
🔁 2. Fixtures for Shared Setup
fixtures/ 폴더에는 재사용 가능한 설정 로직이 포함되어 있습니다, 예:
- 앱으로 이동하기
- 테스트 상태 준비하기
- 공유 테스트 구성
기본 구조 대비 장점
- 테스트는 동작에 집중하고 설정은 최소화
- 테스트 흐름을 표준화하기 쉬움
- 복사‑붙여넣기 실수 감소
🧰 3. 복잡한 로직을 위한 유틸리티
AI 관련 테스트에서는 일부 검증이 간단하지 않습니다(예: 응답 형식 확인, 콘텐츠 규칙 검증, 비동기 동작을 일관되게 처리). 이러한 로직 조각은 utils/에 위치합니다.
이 구조가 기본 구조보다 뛰어난 이유
- 어설션을 재사용 가능하게 유지
- 테스트 파일이 비대해지지 않음
- 테스트를 건드리지 않고 로직을 개선 가능
📁 4. 기능 기반 테스트 그룹화
무작위 스펙 파일 대신, 테스트를 기능별로 그룹화합니다. 예시:
- AI 관련 테스트는 자체 폴더(
tests/ai/)에 위치합니다 - 향후 기능도 동일한 패턴을 따를 수 있습니다
기본 구조와 비교했을 때
- 탐색이 더 쉬워짐
- 소유권이 명확해짐
- 기능이 성장함에 따라 확장성이 향상됨
🧠 최종 생각
주니어 QA 엔지니어라 하더라도, 좋은 구조는 사치가 아니라 기술이라는 것을 배웠습니다.
당신이 필요로 하지 않는 것
- 거대한 프로젝트
- 다년간의 경험
- 완벽한 아키텍처
당신이 정말 필요로 하는 것은 다음과 같은 사고방식입니다: 자동화 테스트는 일회성 스크립트가 아니라 장기적인 자산입니다.
Playwright의 기본 구조를 넘어 테스트를 의도적으로 조직함으로써, 당신은:
- 미래의 고통을 줄인다
- 협업을 개선한다
- 초기부터 더 나은 테스트 습관을 구축한다
희망컨대, 이 글이 다른 주니어 QA들이 제가 아직도 배우고 있는 실수를 피하는 데 도움이 되길 바랍니다 🚀
자유롭게 내 프로젝트 여기 를 살펴보고 참고용으로 사용하세요.