Playwright의 Locator Tool이 충분하지 않을 때

Source: Dev.to

Playwright 내장 로케이터의 한계

Playwright의 내장 로케이터 도구는 대부분의 경우 잘 작동하지만, 실제 컴포넌트 라이브러리를 다루기 시작하면 한계가 드러납니다. 의미론적으로 올바른 컨트롤이 아닌 요소에 대해 getByText나 getByRole을 제안하는 경우가 많아, 이러한 로케이터는 실무에서 불안정하거나 사용할 수 없게 됩니다.

커스텀 체크박스

대부분의 최신 애플리케이션에서는 일반적인 <input> 요소를 거의 보지 못합니다. 대신 div, span, 숨겨진 입력, ARIA 속성, 상태를 나타내는 클래스 등으로 만든 커스텀 컴포넌트를 만나게 됩니다. 이 때문에 toBeChecked나 toBeDisabled와 같은 Playwright 어설션을 신뢰하기 어려워집니다—UI에서는 체크박스가 체크된 것처럼 보이지만, 기본 HTML은 이러한 헬퍼가 기대하는 방식으로 상태를 노출하지 않기 때문입니다.

로케이터 직접 관리하기

이런 경우에는 직접 로케이터를 정의해야 합니다. 가장 신뢰할 수 있는 시작점은 화면에 표시되는 안정적인 텍스트입니다. 해당 텍스트를 기준으로 잡은 뒤, DOM을 위·아래로 이동하면서 실제 체크박스 요소를 찾을 수 있습니다.

Playwright는 이를 위해 locator('..')라는 작지만 매우 유용한 API를 제공합니다. 이는 DOM에서 한 단계 위로 이동하며, 필요에 따라 여러 번 체이닝할 수 있습니다. xpath=../..보다 훨씬 깔끔하고 기억하기도 쉽습니다. 여기서부터 다시 내려가서 우리가 관심 있는 상태를 나타내는 정확한 노드에 도달하면 됩니다.

로케이터 체인 예시

const checkboxLocator = page
  .locator('p.user-select-none', { hasText: 'School-Pupil Activity Bus' })
  .locator('..')
  .locator('..')
  .locator('.special-requirement-checkbox')
  .locator('input[type="checkbox"][aria-checked="true"][disabled="disabled"]');

await expect(checkboxLocator).toBeVisible();

• 앵커는 보이는 라벨 텍스트입니다.
• 로케이터는 공유 컨테이너까지 위로 이동한 뒤, 안정적인 클래스를 가진 래퍼로 다시 내려갑니다.
• 마지막으로 실제 <input> 요소를 목표로 합니다.
• 체크박스가 커스텀이기 때문에, toBeChecked나 toBeDisabled 대신 aria-checked와 disabled 속성을 검증합니다. toBeVisible에 올바른 속성을 조합하면 고수준 어설션 API보다 더 구체적인 검증이 가능합니다.

인간이 만든 로케이터가 여전히 중요한 이유

이 모든 내용은 자동 로케이터와 어설션을 약속하는 AI 테스트 도구에 대해 약간 회의적인 입장을 갖게 하는 이유이기도 합니다. 실제 애플리케이션은 단순하고 의미론적인 HTML 컨트롤을 거의 사용하지 않습니다. 커스텀 마크업, 숨겨진 입력, 프레임워크‑특화 구조 등이 많이 존재하므로 이를 이해하고 탐색해야 합니다. 현재로서는 올바른 텍스트에 앵커를 잡고, DOM을 탐색하며, 실제 속성을 검증할 수 있는 사람이 가장 신뢰할 수 있는 강력한 Playwright 테스트를 작성하는 방법입니다.