본문으로 건너뛰기
중급약 25분

Playwright로 첫 자동화 테스트 작성하기

브라우저를 자동으로 조작하는 Playwright의 기본 구조를 익힌다. 요소를 찾고, 행동을 흉내 내고, 결과를 검증하는 흐름은 모듈 10에서 배운 AAA 패턴 그대로다.

  • #Playwright
  • #웹자동화
  • #UI테스트

개념

Playwright가 하는 일

Playwright는 실제 브라우저(Chromium, Firefox, WebKit)를 코드로 제어하는 도구다. 사람이 하는 클릭·입력·스크롤 같은 행동을 코드로 표현하고, 그 결과 화면에 무엇이 나타나는지 검증한다.

AAA 패턴 그대로, 도구만 다르다

모듈 10(레슨 1)에서 배운 AAA(Arrange-Act-Assert) 패턴이 여기서도 그대로 적용된다.

test("로그인에 성공하면 대시보드로 이동한다", async ({ page }) => {
  // Arrange — 페이지 접속
  await page.goto("https://example.com/login")
 
  // Act — 로그인 정보 입력 후 제출
  await page.getByLabel("이메일").fill("user@example.com")
  await page.getByLabel("비밀번호").fill("password123")
  await page.getByRole("button", { name: "로그인" }).click()
 
  // Assert — 대시보드 화면으로 이동했는지 확인
  await expect(page).toHaveURL(/.*dashboard/)
  await expect(page.getByText("환영합니다")).toBeVisible()
})

page는 브라우저의 한 탭을 가리키는 객체다. goto로 페이지를 열고, getByLabel·getByRole(레슨 3에서 자세히 다룬다)로 요소를 찾아 fill·click으로 행동을 흉내 내고, expect로 결과를 확인한다.

요소를 찾는 방법들

page.getByRole("button", { name: "구매하기" })  // 접근성 역할 기준
page.getByLabel("이메일")                        // 폼 라벨 기준
page.getByText("환영합니다")                     // 화면 텍스트 기준
page.getByTestId("submit-button")                // 테스트 전용 속성 기준

모듈 10(레슨 6)에서 배운 "구현 세부사항이 아니라 사용자 관점으로 테스트한다"는 원칙이 여기서도 핵심이다 — 이 네 가지 방법 중 어느 것을 선택할지가 레슨 3의 주제다.

자동 대기(Auto-waiting)

Playwright는 요소를 클릭하기 전에, 그 요소가 화면에 나타나고 클릭 가능한 상태가 될 때까지 자동으로 기다린다. 이건 레슨 5에서 자세히 다룰 대기 전략의 핵심 개념으로, 옛날 도구들(Selenium 초기 버전 등)에서 흔했던 "요소를 못 찾아서 실패하는" 문제를 상당 부분 줄여준다.

디버깅 도구

Playwright는 테스트가 실패했을 때 무슨 일이 있었는지 확인할 수 있는 도구를 제공한다.

  • 스크린샷 — 실패 시점의 화면을 자동으로 저장
  • 트레이스(Trace) — 테스트 실행 전체 과정을 녹화해, 각 단계에서 화면이 어땠는지 재생해볼 수 있음
  • 비디오 — 테스트 실행 전체를 영상으로 기록

이 도구들은 모듈 6(레슨 2)에서 배운 "증거자료"를 자동으로 만들어 주는 셈이다 — 자동화 테스트가 실패했을 때, 사람이 직접 재현하지 않아도 무엇이 잘못됐는지 확인할 수 있다.

실무에서 왜 필요한가

Playwright로 작성된 테스트 코드를 읽을 줄 알면, 개발자가 "이 흐름은 자동화로 커버돼 있어요"라고 할 때 실제로 어떤 요소를, 어떤 방식으로 찾아서 검증하는지 확인할 수 있다. 트레이스나 스크린샷을 활용하면, CI에서 자동화 테스트가 실패했을 때 QA가 직접 재현하지 않고도 1차 원인 파악을 할 수 있어 왕복 시간이 크게 줄어든다.

실습 과제

과제 1 — 테스트 코드 완성하기 (15분)

"장바구니에 상품을 담으면 장바구니 아이콘의 개수 배지가 1 증가한다"는 시나리오를, 이 레슨의 예시 형식을 참고해 Arrange-Act-Assert 구조로 의사코드(pseudocode) 형태로 작성한다.

과제 2 — 디버깅 도구 활용 계획 (10분)

CI에서 어떤 UI 자동화 테스트가 가끔 실패한다는 제보를 받았다. 트레이스와 스크린샷 중 어떤 것을 먼저 확인할지, 그리고 그걸로 무엇을 알아내려 하는지 계획을 적는다.

자가 체크리스트

  • Playwright 테스트 코드에서 AAA 패턴의 각 부분을 식별할 수 있다
  • 요소를 찾는 네 가지 방법(getByRole 등)을 나열할 수 있다
  • 자동 대기가 무엇을 자동으로 해주는지 설명할 수 있다
  • 스크린샷·트레이스·비디오가 디버깅에 어떻게 도움이 되는지 설명할 수 있다

흔한 실수

  • 모든 요소를 CSS 선택자나 XPath로만 찾으려 한다. 사용자 관점의 방법(getByRole 등)이 더 안정적이다 — 레슨 3에서 자세히 다룬다.
  • 자동 대기가 있으니 모든 타이밍 문제가 해결된다고 오해한다. 일부 상황에서는 여전히 명시적인 대기가 필요하다(레슨 5).
  • 테스트 실패 시 디버깅 도구를 켜두지 않아, 무슨 일이 있었는지 전혀 알 수 없다. CI 설정에서 실패 시 스크린샷·트레이스가 저장되도록 미리 구성해두는 것이 좋다.

참고 자료