부서지기 쉬운 테스트 작성을 멈추세요: 모든 Playwright 개발자가 필요로 하는 스마트 로케이터 전략

Source: Dev.to

나는 한 줄의 XPath 때문에 깨진 불안정한 테스트를 디버깅하는 데 몇 시간을 보냈다.
해결책? 10초 만에 작성한 단 하나의 Playwright 로케이터.

내가 미리 알았으면 좋았을 내용은 다음과 같다.

어려운 진실

테스트가 불안정하다면, 로케이터가 문제다.

전통적인 XPath와 CSS 선택자는 DOM을 트리처럼 탐색한다. 개발자가 요소의 순서를 바꾸거나 구조를 변경하는 순간—테스트가 깨진다. 매번. 반드시.

// 깨지기 쉬움 – DOM 구조가 바뀌면 실패
page.locator('div#main > ul:nth-child(2) > li:first-child > button')

인간 시각 vs 로봇 시각

Playwright는 전혀 다른 접근 방식을 취한다. ID와 클래스 이름을 찾아다니는(로봇 시각) 대신, 실제 사용자가 화면에서 보는 것(인간 시각)으로 요소를 대상으로 한다.

최고의 기준? page.getByRole()

이는 접근성 트리에 기반한다—스크린 리더가 사용하는 동일한 구조다. 스크린 리더가 찾을 수 있으면 Playwright도 테스트할 수 있다. 그리고 리팩터링에도 살아남는다.

// 스마트 – DOM 변경에도 살아남음
page.getByRole('button', { name: 'Sign up' })

로케이터 우선순위 계층

다음 순서를 따르면 로케이터 문제의 80 %를 해결할 수 있다:

1. getByRole – 여기서 시작하라. 버튼, 헤딩, 체크박스, 링크 등 대부분에 적용된다.
2. getByText / getByLabel – 화면에 보이는 텍스트나 폼 라벨을 백업으로 사용한다.
3. getByTestId – 개발자에게 data-testid 속성을 추가하도록 요청한다. 안정적이며 실수로 바뀌지 않는다.
4. CSS/XPath – 최후의 수단만 사용한다. 그래도 필요하면 LLM에 붙여넣어 getByRole 로케이터로 변환하도록 하라.

보너스: sleep() 해킹은 이제 그만

Playwright의 내장 자동 대기 기능 덕분에 모든 로케이터는 요소가 DOM에 붙어있고, 보이고, 안정적이며, 활성화될 때까지 자동으로 기다린다. 임의의 타임아웃이 필요 없다.

// 더 이상 필요 없음
await page.waitForTimeout(3000);

// 접근성 트리를 활용한 권장 방식
const submitButton = await page.getByRole('button', { name: 'Submit' });
await submitButton.click();

이 글은 Playwright 80/20 파레토 원칙 시리즈의 Part 2이다. Part 3에서는 Playwright Actions를 다룰 예정이며, 곧 공개된다!

🎬 전체 영상 보기: https://www.youtube.com/watch?v=6IaCQ70cNVc