Playwright에서 안정적인 locator를 선택하는 기준은 무엇인가요?

Playwright에서는 getByRole, getByLabel처럼 사용자 관점의 locator를 우선합니다. DOM 구조에 강하게 의존하는 CSS 선택자는 리팩터링에 취약합니다.

핵심 개념

핵심 기준은 사용자 관점 선택자와 DOM 구조 의존성입니다.

E2E 테스트는 사용자가 실제로 인식하고 조작하는 UI를 기준으로 작성할수록 오래 유지됩니다. class, nth-child, 깊은 CSS selector는 DOM 구조 변경에 취약합니다. role, label, text, test id 순으로 의도를 분명히 드러내는 locator를 선택하는 것이 좋습니다.

동작 흐름

1. 검증하려는 위험을 먼저 정의합니다.
2. 입력 데이터, 실행 조건, 기대 결과를 명확히 둡니다.
3. 자동화 비용과 실행 빈도에 맞게 테스트 범위를 조정합니다.
4. 실패 시 로그와 지표로 원인을 추적할 수 있게 만듭니다.

실제 예시

await page.getByRole('textbox', { name: '이메일' }).fill('ada@example.com');
await page.getByRole('button', { name: '로그인' }).click();
await expect(page.getByRole('heading', { name: '대시보드' })).toBeVisible();

예시는 핵심 흐름을 단순화한 것입니다. 실무에서는 팀의 배포 방식, 데이터 크기, 장애 영향도, 유지보수 비용까지 함께 고려해야 합니다.

실무에서 주의할 점

• 구현 세부사항에 과하게 묶인 테스트는 리팩터링 때 쉽게 깨집니다.
• 느리고 불안정한 테스트를 방치하면 팀이 테스트 결과를 믿지 않게 됩니다.
• 커버리지 숫자보다 중요한 시나리오와 경계값을 검증하는지가 더 중요합니다.

함께 연결해서 보면 좋은 키워드

Playwright, Locator, E2E, Accessibility

정리

한 줄로 정리하면, Playwright에서는 getByRole, getByLabel처럼 사용자 관점의 locator를 우선합니다. DOM 구조에 강하게 의존하는 CSS 선택자는 리팩터링에 취약합니다. 개념의 정의뿐 아니라 적용 조건과 실패했을 때의 증상까지 함께 이해하는 것이 중요합니다.