Playwright fixtures란? 매번 같은 상태에서 시작하고 자동으로 돌리기

테스트를 몇 개 적고 나면 같은 준비 과정이 반복됩니다. 로그인하고, 데이터를 만들고, 특정 화면까지 이동하는 일입니다. Playwright는 이 준비 과정을 Playwright fixtures 라는 이름으로 따로 떼어 관리하고, 테스트마다 필요한 것만 꺼내 쓰게 합니다. 그리고 이렇게 정리해 둔 테스트는 배포할 때마다 자동으로 실행되도록 연결할 수 있습니다.

테스트가 서로에게 영향을 주는 문제

테스트를 여러 개 돌릴 때 가장 자주 겪는 상황이 있습니다. 하나씩 실행하면 다 통과하는데, 한꺼번에 돌리면 일부가 실패합니다.

원인은 대개 앞 테스트가 남긴 상태입니다. 처음 시작하기 편에서 만든 예제를 여러 개로 늘리면 바로 겪게 됩니다. 앞에서 만든 데이터가 남아 있거나, 로그인 상태가 유지되거나, 화면이 이전 단계에 머물러 있는 경우입니다. 테스트끼리 서로에게 영향을 주면 결과를 믿기 어려워집니다. 실패했을 때 그 테스트가 잘못된 것인지, 앞의 테스트 때문인지 알 수 없기 때문입니다.

Playwright는 이 문제를 구조로 막습니다. 테스트마다 새 브라우저 환경을 주는 것이 기본 동작입니다.

Playwright fixtures 는 테스트마다 새 화면과 빈 저장소를 건네줍니다

Playwright fixtures 가 하는 일

fixtures는 테스트에 필요한 환경을 준비해 건네주는 장치입니다. 공식 문서는 그 목적을 "테스트에 필요한 것을 모두 주고, 그 외에는 아무것도 주지 않는다"고 설명합니다.

기본으로 제공되는 것들이 있습니다.

앞선 글들에서 계속 나온 page가 바로 이것입니다.

test('대시보드가 보인다', async ({ page }) => {
  await page.goto('/dashboard');
});

중괄호 안에 적은 page는 그냥 변수가 아니라 필요한 것을 요청하는 자리입니다. 이렇게 적으면 Playwright가 이 테스트만을 위한 새 화면을 만들어 건네줍니다. 앞 테스트가 무엇을 했든 영향을 받지 않습니다.

beforeEach와 무엇이 다른가

준비 과정을 정리하는 방법으로 beforeEach도 있습니다. 매 테스트 전에 실행되는 구간을 만드는 방식입니다. fixtures는 여기서 몇 가지가 다릅니다.

• 준비와 정리가 한자리에 있습니다. 만들어 주는 코드와 치우는 코드가 같은 곳에 있어 나중에 고치기 쉽습니다.
• 필요한 테스트만 준비합니다. 요청하지 않은 테스트에서는 그 준비가 아예 실행되지 않습니다.
• 여러 파일에서 다시 씁니다. 한 번 정의해 두면 파일마다 옮겨 적지 않아도 됩니다.
• 서로 겹쳐 쓸 수 있습니다. 한 준비가 다른 준비를 필요로 하는 관계를 만들 수 있습니다.

정리하면 beforeEach는 "이 파일의 모든 테스트가 이 준비를 거친다"이고, fixtures는 "이 테스트가 이 준비를 요청한다"입니다. 요청하는 쪽이 테스트라서, 테스트 파일만 읽어도 무엇이 필요한 테스트인지 드러납니다.

내 준비 과정 만들기

자주 쓰는 준비는 직접 만들어 둘 수 있습니다. 로그인한 상태를 예로 들겠습니다.

import { test as base } from '@playwright/test';

export const test = base.extend<{ loggedInPage: Page }>({
  loggedInPage: async ({ page }, use) => {
    await page.goto('/login');
    await page.getByLabel('이메일').fill('me@example.com');
    await page.getByLabel('비밀번호').fill('비밀번호');
    await page.getByRole('button', { name: '로그인' }).click();

    await use(page);
  },
});

use 앞은 준비, 뒤는 정리입니다. 이제 테스트는 로그인 절차를 몰라도 됩니다.

test('주문 내역이 보인다', async ({ loggedInPage }) => {
  await loggedInPage.goto('/orders');
});

로그인 화면이 바뀌면 고칠 곳은 fixtures.ts 한 곳입니다. 테스트가 50개여도 마찬가지입니다.

테스트 자동화 — 배포마다 자동으로 돌리기

여기까지 하면 테스트는 잘 정리됐지만, 손으로 실행하는 동안에는 잊어버리기 쉽습니다. 자동으로 돌게 만들어야 합니다.

설치할 때 자동 실행 설정을 함께 만들겠냐고 묻는 단계가 있었는데, 그때 예를 골랐다면 .github/workflows/playwright.yml이 이미 만들어져 있습니다. 공식 문서에 따르면 이 설정은 다음과 같이 동작합니다.

• 주 브랜치에 코드가 올라가거나 병합 요청이 생길 때 실행됩니다
• 필요한 것을 설치하고, 브라우저를 받고, 테스트를 돌립니다
• 실행 결과를 30일간 보관합니다

결과가 보관된다는 점이 중요합니다. 실패했을 때 그 결과물을 내려받아 압축을 풀고 결과 화면을 열면, 그 서버에서 일어난 일을 그대로 되감아 볼 수 있습니다.

코드를 올리면 테스트가 자동 실행되고 결과는 기본 30일 보관됩니다

이어서 읽기Playwright trace viewer란? 테스트가 실패했을 때 남는 것playwright trace viewerPlaywright5분

시리즈를 닫으며 — 도구가 하지 않는 일

이 시리즈에서 다룬 것을 모으면 이렇게 됩니다.

• AI에게 테스트를 맡기는 방법과 그 경계
• 조작을 코드로 받아 적는 방법
• 화면이 바뀌어도 멈추지 않게 요소를 지목하는 방법
• 실패했을 때 조사할 수 있게 기록을 남기는 방법
• 설치부터 첫 실행까지
• 준비 과정을 정리하고 자동으로 돌리는 방법

여기까지 갖추면 실행은 사람 손을 떠납니다. 그런데 시리즈 내내 같은 자리에서 같은 것이 남았습니다.

무엇을 확인할지 정하는 일입니다.

도구는 정해 준 것만 확인합니다. 화면이 바뀌었을 때 그것이 의도한 변경인지 아닌지도 판단하지 않습니다. 이 판단에는 무엇이 맞는 상태인지에 대한 기준이 필요하고, 그 기준은 코드 안에 없습니다.

실행은 이미 무료로 해결된 영역입니다. Playwright가 훌륭하게 풀어 놨습니다. 남은 빈자리는 그 앞 단계입니다.

이어서 읽기Playwright MCP란? 강점 7가지와 상황별 선택 3가지playwright mcpplaywright9분

Specnote는 그 앞 단계를 맡습니다

Specnote는 무엇이 만들어졌는지 먼저 확인하고, 그 범위만 테스트하는 순서를 제품으로 만든 도구입니다. AI가 무엇을 만들었는지 목록으로 정리해 보여 주고, 사람이 그 목록에서 틀린 것을 빼고 빠진 것을 더해 승인하면, 승인된 범위만 실제 브라우저에서 확인합니다.

코드를 읽고 고칠 수 있다면 이 시리즈대로 Playwright를 쓰시는 편이 더 정밀하고 자유롭습니다. 저희가 겨냥한 자리는 그 일을 할 시간이나 사람이 없는 쪽입니다.

이 글의 기술 내용은 Playwright 공식 문서 · Fixtures와 CI GitHub Actions를 기준으로 2026년 8월 21일에 확인했습니다.