Playwright로 스크린샷 테스트하는 방법

스크린샷 테스트는 현재 페이지 모습을 이전에 승인된 이미지와 비교합니다. 픽셀 차이가 허용치를 넘으면 테스트가 실패하고 차이를 보여줍니다. Playwright Test는 별도 플러그인 없이 expect(page).toHaveScreenshot()으로 이 기능을 제공합니다. 이 방법은 visual regression testing이라고도 부릅니다.

이 가이드의 예시는 하나의 테스트 스위트를 구성합니다. 브라우저 프로젝트 3개에서 마케팅 및 앱 페이지 12개와 공용 컴포넌트 8개를 테스트합니다. 아래의 모든 수치, 기준 이미지 개수부터 차이 허용값까지는 이 스위트에서 나온 값입니다.

스크린샷 테스트가 가치 있는 경우

시각 테스트는 DOM 검증으로 잡히지 않는 문제를 찾습니다. 예를 들면 스타일시트 로드 실패, 화면 밖으로 밀린 버튼, 시스템 기본 글꼴로 대체된 폰트가 있습니다. 다음 경우에 유지 비용을 들일 가치가 있습니다.

• 디자인 시스템이나 여러 페이지에서 쓰는 공용 컴포넌트가 있는 UI
• CSS 변경이 잦아 검토자가 모든 페이지를 직접 확인하기 어려운 경우
• 레이아웃 버그가 이전에 프로덕션까지 나간 경우

라이브 데이터, 광고, 사용자 콘텐츠가 많은 페이지에서는 실행할 때마다 결과가 달라서 얻는 것보다 비용이 큽니다. 스위트가 잡음으로 가득 찹니다.

테스트 작성 전 스위트 규모 확인

검증 하나는 프로젝트마다 기준 이미지 하나를 만듭니다. 예시 스위트에는 전체 페이지 검증 12개와 컴포넌트 검증 8개가 있고, 각각 프로젝트 3개에서 실행됩니다. 따라서 생성, 검토, 보관해야 할 PNG 파일은 60개입니다.

스위트에서 제외할 페이지

실행할 때마다 실패하는 페이지가 있습니다. 실시간 차트가 있는 대시보드, 사용자 게시물 피드, 배너가 돌아가는 페이지가 여기에 속합니다. 이런 페이지에는 빈 상태 화면이나 고정 데이터를 넣은 컴포넌트를 대신 테스트합니다.

예시 팀은 후보 페이지 5개를 스위트에서 뺐습니다. 대시보드 2개, 매주 새 글이 올라오는 블로그 목록, 상태 페이지, 검색 결과 페이지입니다. 각 페이지는 공용 부분에 대한 요소 검증으로 대신 다룹니다. 전체 페이지 목록은 12개로 유지했습니다.

긴 마케팅 페이지의 전체 페이지 PNG는 1MB 이상이 될 수 있습니다. 이런 파일 60개는 기준 이미지가 바뀔 때마다 Git 기록에 쌓입니다. 컴포넌트 검증은 파일이 작고 변경도 적어서 스위트의 대부분을 담당합니다.

Playwright Test 설치

npm init playwright@latest

설치 도구는 playwright.config.ts, 예시 테스트 폴더, 선택 사항인 CI 워크플로를 만들고 브라우저를 내려받습니다. 스크린샷 검증에 추가로 필요한 것은 없습니다.

Playwright 버전 고정

Playwright 릴리스마다 고정된 브라우저 빌드가 포함됩니다. 브라우저가 업데이트되면 텍스트 렌더링이 약간 달라져서 변경하지 않은 스크린샷 테스트도 실패할 수 있습니다. package.json에 정확한 버전을 고정하고, 버전 업데이트는 별도 풀 리퀘스트에서 진행합니다.

{
  "devDependencies": {
    "@playwright/test": "1.48.0"
  }
}

버전이 바뀌면 같은 풀 리퀘스트에서 기준 이미지를 모두 다시 생성하고 한 묶음으로 검토합니다. 버전 업데이트와 기능 변경을 섞으면 어떤 변경이 차이를 만들었는지 알 수 없습니다.

첫 스크린샷 테스트 만들기

// tests/visual.spec.ts
import { test, expect } from '@playwright/test';

test('home page matches baseline', async ({ page }) => {
  await page.goto('https://example.com/');
  await expect(page).toHaveScreenshot('home.png', { fullPage: true });
});

첫 실행에는 비교할 기준 이미지가 없습니다. Playwright는 캡처를 기대 이미지로 저장하고, 새 기준 이미지를 검토하도록 테스트를 실패시킵니다. npx playwright test를 다시 실행하면 저장된 파일과 비교해 테스트가 통과합니다.

이후 실행에서 차이가 나면 Playwright는 기대 이미지, 실제 캡처, 변경된 픽셀을 강조한 차이 이미지를 저장합니다. npx playwright show-report가 여는 HTML 리포트에서 세 이미지를 모두 볼 수 있습니다.

페이지 목록 하나로 12개 페이지 테스트

테스트 12개를 따로 쓰면 같은 코드가 반복됩니다. 페이지 목록과 반복문으로 페이지마다 이름이 붙은 테스트 하나를 만듭니다. 테스트 제목에 페이지 이름이 들어가므로 나중에 -g로 한 페이지만 지정할 수 있습니다.

// tests/pages.visual.spec.ts
import { test, expect } from '@playwright/test';

const pages = [
  { name: 'home', path: '/' },
  { name: 'pricing', path: '/pricing' },
  { name: 'features', path: '/features' },
  { name: 'docs-index', path: '/docs' },
  // ...8 more entries
];

for (const p of pages) {
  test(`page ${p.name} matches baseline`, async ({ page }) => {
    await page.goto(p.path);
    await page.getByRole('heading', { level: 1 }).waitFor();
    await page.evaluate(() => document.fonts.ready);
    await expect(page).toHaveScreenshot(`${p.name}.png`, { fullPage: true });
  });
}

상대 경로를 쓰려면 설정에 baseURL이 필요합니다. 다음 절에서 로컬 웹 서버와 함께 설정합니다.

프로덕션이 아닌 로컬 빌드로 실행

프로덕션 페이지는 테스트 대상 코드와 무관한 이유로 바뀝니다. 콘텐츠 수정, A/B 테스트, 서드파티 스크립트가 그 예입니다. 브랜치의 로컬 빌드는 브랜치가 바꾼 내용만 보여줍니다. webServer 옵션은 테스트 전에 이 빌드를 시작합니다.

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  use: { baseURL: 'http://localhost:3000' },
  webServer: {
    command: 'npm run build && npm run start',
    url: 'http://localhost:3000',
    reuseExistingServer: !process.env.CI,
    timeout: 120_000,
  },
});

reuseExistingServer를 켜면 개발자가 로컬 실행 중에 직접 띄워 둔 서버를 그대로 쓸 수 있습니다. CI에서는 값이 false이므로 작업마다 새 빌드를 시작합니다.

페이지의 일부분 테스트

test('pricing card', async ({ page }) => {
  await page.goto('https://example.com/pricing');
  await expect(page.getByTestId('pro-plan')).toHaveScreenshot('pro-card.png');
});

요소 단위 검증은 범위가 작아서 관련 없는 이유로 실패하는 경우가 적습니다. 헤더를 바꿔도 가격 카드 테스트는 깨지지 않습니다. 핵심 페이지 몇 개에는 전체 페이지 검증을, 컴포넌트에는 요소 검증을 사용합니다.

페이지마다 검증 방식 선택

예시 스위트의 페이지 12개는 페이지 유형 4개로 나뉩니다. 사람이 전체를 보고 판단하는 페이지만 전체 페이지 검증을 받습니다. 공용 컴포넌트로 만든 페이지는 해당 컴포넌트에 요소 검증을 붙입니다.

브라우저 및 기기 프로젝트 추가

playwright.config.ts의 프로젝트는 같은 테스트를 여러 브라우저와 기기 프로필에서 실행합니다.

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
    { name: 'mobile', use: { ...devices['iPhone 13'] } },
  ],
});

프로젝트마다 기준 이미지를 따로 보관합니다. 파일 이름에는 프로젝트와 플랫폼이 들어갑니다. 예를 들면 home-chromium-darwin.png입니다. 프로젝트가 3개면 검증 하나당 기준 이미지가 3개 생기므로, 레이아웃이 실제로 다른 경우에만 프로젝트를 추가합니다.

기준 이미지를 예측 가능한 한 폴더에 보관

기본 위치는 각 테스트 파일 옆의 -snapshots 폴더입니다. 테스트 파일이 여러 개이면 기준 이미지가 테스트 트리 전체에 흩어집니다. snapshotPathTemplate 옵션은 공용 루트 아래 테스트 파일마다 폴더 하나로 기준 이미지를 모읍니다.

// playwright.config.ts
export default defineConfig({
  snapshotPathTemplate: '{testDir}/__screenshots__/{testFilePath}/{arg}{-projectName}{ext}',
});

이 템플릿은 플랫폼 접미사를 뺍니다. 모든 실행이 같은 Linux Docker 이미지에서 이루어지면 충돌이 없기 때문입니다. 일부 실행이 아직 macOS에서 이루어진다면 템플릿에 {-snapshotSuffix}를 남겨서 두 플랫폼의 파일이 섞이지 않게 합니다.

리뷰어는 폴더 하나를 열어 spec 파일의 모든 기준 이미지를 볼 수 있습니다. 테스트 파일 이름을 바꾸면 기준 이미지도 새 폴더로 옮겨지므로, 이름 변경은 기준 이미지를 다시 생성하는 풀 리퀘스트에서 함께 진행합니다.

페이지 상태를 안정적으로 유지

스크린샷은 매번 같은 상태에 도달할 때만 비교할 수 있습니다.

1. 검증 전에 제목이나 로드된 이미지 같은 준비 완료 요소를 기다림
2. 실제 계정 대신 고정된 테스트 데이터를 사용함
3. 설정에서 고정된 뷰포트를 지정함
4. await page.evaluate(() => document.fonts.ready)로 웹 폰트를 기다림

toHaveScreenshot은 연속된 두 캡처가 일치할 때까지 재시도하고, 기본값으로 CSS 애니메이션을 멈춥니다. 이 두 동작만으로 추가 코드 없이 시간에 따른 잡음 대부분이 제거됩니다.

고정 시간이 아니라 신호를 기다림

고정된 page.waitForTimeout(3000)은 스위트를 느리게 만들고, 느린 러너에서는 여전히 실패합니다. 특정 요소를 기다리면 검증이 페이지 상태에 연결됩니다. 위 페이지 반복문의 제목 대기가 그 예입니다.

네트워크가 유휴 상태가 되기를 기다리는 방식은 생각보다 신뢰도가 낮습니다. API를 폴링하거나 연결을 계속 열어 두는 페이지는 그 상태에 도달하지 않아서 대기가 시간 초과로 끝납니다. 데이터가 로드된 뒤에만 나타나는 요소, 예를 들어 표의 첫 행을 기다리는 방식을 권장합니다.

화면 아래쪽의 지연 로딩 이미지는 스크롤해서 보이기 전까지 로드되지 않습니다. 이런 페이지의 전체 페이지 캡처에는 빈 상자가 보입니다. 검증 전에 한 번 아래까지 스크롤하거나, 테스트 빌드에서 지연 로딩을 끕니다.

시간을 고정하고 서드파티 스크립트 차단

"3분 전 업데이트"처럼 날짜 표현은 실행할 때마다 바뀝니다. 시계 API는 페이지가 보는 시간을 고정합니다. 채팅 위젯과 분석 스크립트는 나중에 요소를 삽입할 수 있으므로, 테스트는 네트워크 수준에서 이들을 차단합니다.

test.beforeEach(async ({ page }) => {
  await page.clock.setFixedTime(new Date('2026-05-01T10:00:00Z'));
  await page.route(/(analytics|chat-widget)\./, (route) => route.abort());
});

스크립트를 차단하면 그 스크립트가 그리는 요소도 함께 사라집니다. 이는 의도된 동작입니다. 시각 테스트는 위젯이 아니라 사이트 자체의 레이아웃을 검증하기 때문입니다.

불안정 원인과 해결 방법

예시 스위트는 도입 후 첫 2주 동안 코드 변경 없이 9번 실패했습니다. 각 실패는 원인 5가지 중 하나로 추적되었습니다. 아래 표는 원인마다 이를 막은 변경을 짝지어 보여줍니다.

특정 요소 숨기기 또는 마스킹

await expect(page).toHaveScreenshot('dashboard.png', {
  mask: [page.locator('.timestamp'), page.locator('.user-avatar')],
});

마스킹된 영역은 두 이미지 모두에서 단색 상자로 가려지므로 그 안의 내용은 검사하지 않습니다. 요소를 완전히 없애려면 stylePath 옵션으로 스타일시트를 전달해 해당 요소를 숨깁니다. 요소를 삭제하는 것보다 마스킹이 낫습니다. 주변 레이아웃은 여전히 검사되기 때문입니다.

레이아웃이 아니라 역할로 마스킹

레이아웃 클래스에 의존하는 마스크 로케이터는 마크업이 바뀌면 깨집니다. 테스트 ID나 접근성 역할은 디자인이 바뀌어도 유지됩니다. 예시 스위트에서는 휘발성 요소마다 data-testid가 volatile-로 시작합니다.

await expect(page).toHaveScreenshot('account.png', {
  mask: [page.locator('[data-testid^="volatile-"]')],
  maskColor: '#FF00FF',
});

밝은 maskColor는 리포트에서 마스킹된 상자를 눈에 띄게 합니다. 리뷰어는 테스트가 무시하는 영역을 한눈에 확인할 수 있습니다.

차이 허용값 신중하게 설정

옵션	의미
maxDiffPixels	달라도 되는 픽셀 수.
maxDiffPixelRatio	달라도 되는 픽셀 비율, 0에서 1 사이.
threshold	한 픽셀의 색상 차이가 얼마 이상이어야 차이로 세는지, 0에서 1 사이. 기본값 0.2.

허용값은 낮게 유지합니다. 1280×4000 전체 페이지 캡처에서 maxDiffPixelRatio 0.01은 픽셀의 1퍼센트, 즉 50,000개 이상이 바뀌어도 허용한다는 뜻입니다. 이 정도면 누락된 아이콘도 숨길 수 있습니다. maxDiffPixels는 100 안팎으로 시작하고, 특정 거짓 실패가 확인될 때만 조정합니다.

전체 페이지 캡처 하나의 임계값 계산

아래 수치는 예시의 가격 페이지 크기인 1280×4000 픽셀 캡처 하나를 기준으로 합니다. 24×24 픽셀 아이콘은 576픽셀을 차지합니다. 비율 기준 허용치를 1퍼센트로 두면 허용치 안에 이 아이콘이 약 88개 분량 들어가므로, 아이콘이 사라져도 실패하지 않습니다.

설정에서 기본값 한 번에 지정

검증 호출마다 옵션을 넣으면 새 테스트에서 빠뜨리기 쉽습니다. 설정 파일의 expect.toHaveScreenshot 블록은 모든 검증의 기본값을 정합니다. 개별 테스트는 여전히 이 값을 덮어쓸 수 있습니다.

// playwright.config.ts
export default defineConfig({
  expect: {
    toHaveScreenshot: {
      maxDiffPixels: 100,
      threshold: 0.2,
      animations: 'disabled',
      caret: 'hide',
      scale: 'css',
    },
  },
});

scale: 'css'를 지정하면 CSS 픽셀 1개가 이미지 픽셀 1개와 같아집니다. 그래서 Retina 계열 기기 프로필을 써도 이미지 크기가 두 배가 되지 않습니다. 기준 이미지가 작아지고 위의 픽셀 계산도 그대로 유효합니다.

기준 이미지 검토와 업데이트

디자인 변경이 의도된 것이면 영향을 받는 기준 이미지를 다시 생성합니다.

npx playwright test --update-snapshots

파일 이름이나 -g와 테스트 제목을 지정해 실패한 테스트만 업데이트합니다. 스위트 전체를 일괄 업데이트하면 의도하지 않은 변경을 놓치기 쉽습니다.

npx playwright test tests/pages.visual.spec.ts -g "page pricing" --update-snapshots

세 이미지를 순서대로 읽기

차이 이미지보다 실제 캡처를 먼저 봅니다. 실제 캡처를 보면 사람이 보기에 페이지가 깨졌는지 알 수 있습니다. 그다음 차이 이미지에서 픽셀이 바뀐 위치를 찾고, 기대 이미지에서 이전 모습을 확인합니다.

차이 이미지는 바뀐 픽셀을 빨간색으로 표시합니다. 텍스트 블록마다 가는 빨간 윤곽선이 보이면 보통 폰트나 안티앨리어싱 변경이며 레이아웃 버그가 아닙니다. 한 곳에 빨간 사각형이 꽉 차 있으면 보통 요소가 움직였거나 나타났거나 사라진 것입니다.

HTML 리포트는 기대 이미지와 실제 이미지를 비교하는 슬라이더 보기도 제공합니다. 변경된 영역에서 슬라이더를 움직이면 차이 이미지보다 작은 이동, 예를 들어 2픽셀 여백 변경이 더 분명하게 보입니다.

기준 이미지 하나의 생애

기준 이미지는 페이지가 의도적으로 바뀔 때마다 같은 순환을 거칩니다. 판단 지점은 차이가 의도된 것인지 정하는 한 곳뿐이고, 나머지는 기계적인 절차입니다.

풀 리퀘스트에서 기준 이미지 변경 검토

풀 리퀘스트의 변경된 PNG는 코드 변경입니다. GitHub와 대부분의 리뷰 도구는 이미지 차이를 나란히 보여줍니다. 아래 체크리스트는 예시 팀의 검토자가 승인 전에 확인하는 항목입니다.

CI에서 스크린샷 테스트 실행

macOS에서 만든 기준 이미지는 Linux 러너의 캡처와 일치하지 않습니다. 폰트와 안티앨리어싱이 다르기 때문입니다. 안정적인 방법은 같은 환경에서 기준 이미지를 생성하고 비교하는 것입니다. 보통 설치된 패키지와 같은 버전의 공식 Playwright Docker 이미지를 사용합니다.

실행 가능한 절차는 다음과 같습니다.

1. 개발자가 macOS가 아니라 Docker 이미지 안에서 시각 테스트 스위트를 실행함
2. CI가 같은 이미지에서 실행하고, 실패하면 HTML 리포트를 아티팩트로 업로드함
3. 의도된 변경의 새 기준 이미지를 코드 변경과 함께 커밋함
4. 검토자가 풀 리퀘스트에서 이미지 차이를 확인함

Mac에서 Docker로 기준 이미지 생성

이미지 태그는 고정된 Playwright 버전과 일치해야 합니다. 버전이 어긋나면 이미지가 제거하려던 폰트와 렌더링 차이가 다시 나타납니다. 프로젝트 루트에서 명령을 실행합니다.

docker run --rm --ipc=host -v "$(pwd)":/work -w /work \
  mcr.microsoft.com/playwright:v1.48.0-noble \
  /bin/bash -c "npm ci && npx playwright test --update-snapshots -g 'page pricing'"

시각 테스트 스위트용 CI 작업

작업은 같은 이미지 안에서 실행되므로 브라우저 다운로드 단계가 필요 없습니다. 테스트가 실패한 경우에만 리포트를 업로드합니다. 리포트에는 실패마다 기대 이미지, 실제 이미지, 차이 이미지가 들어 있습니다.

# .github/workflows/visual.yml
name: visual
on: pull_request
jobs:
  visual:
    runs-on: ubuntu-latest
    container:
      image: mcr.microsoft.com/playwright:v1.48.0-noble
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx playwright test tests/*.visual.spec.ts
        env:
          HOME: /root
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report
          path: playwright-report/

예시에서 전체 작업은 약 5분이 걸립니다. 풀 리퀘스트마다 컴포넌트 검증 8개만 실행하고 페이지 검증 36개는 main 브랜치에서만 실행하면, 풀 리퀘스트 작업이 3분 미만으로 줄어듭니다.

일반 스크린샷 자동화가 맞는 경우

시각 테스트는 한 가지 질문에 답합니다. 이 페이지가 기준 이미지와 비교해 바뀌었는가입니다. 디자인 회의, 고객 보고서, 날짜별 보관용 검토 세트는 만들지 않으며, 엔지니어링 외부의 사람들은 거의 실행하지 않습니다.

이런 작업에는 일반 캡처 도구가 더 단순합니다. Temposhot Website Capture는 Mac에서 URL 목록을 받아 테스트 코드 없이 각 페이지를 Desktop 1920×1080, Tablet 768×1024 또는 Mobile 390×844 크기로 캡처합니다. 두 캡처를 눈으로 비교하려면 Compare Images가 브라우저에서 차이를 강조합니다. 스크린샷 비교 항목은 일반적인 방법을 설명합니다.

서로 다른 두 질문에 두 도구

같은 팀에서 시각 테스트 스위트와 캡처 도구를 함께 쓰는 경우가 많습니다. 엔지니어는 스위트를 관리합니다. 디자이너와 제품 관리자는 캡처를 검토와 보관에 사용합니다.

자주 하는 실수

• 노트북에서 만든 기준 이미지를 커밋하고 Linux CI에서 비교함
• 날짜, 캐러셀, 광고가 포함된 전체 페이지를 검증함
• 페이지 상태를 고치는 대신 임계값을 높여 불안정한 테스트를 잠잠하게 만듦
• 의도한 변경 하나 뒤에 스위트 전체에 --update-snapshots를 실행함
• 데스크톱 기준 이미지가 안정되기 전에 기기 프로젝트를 많이 추가함

실패한 시각 빌드 분류

실패한 시각 작업은 재실행이 아니라 판단이 필요합니다. 불안정한 테스트를 통과할 때까지 재실행하면 원인이 가려지고, 다음 실제 회귀가 그대로 통과합니다. 아래 순서로 대부분의 실패를 몇 분 안에 정리할 수 있습니다.

1. 리포트 아티팩트를 내려받고 실패한 검증 개수를 셈함
2. 한 프로젝트의 검증이 모두 실패했다면 해당 프로젝트의 브라우저나 폰트 변경을 먼저 확인함
3. 한 페이지가 프로젝트 3개에서 모두 실패했다면 실제 이미지를 열어 봄. 원인은 보통 페이지 자체에 있음
4. 한 페이지가 한 프로젝트에서만 실패했다면 브라우저별 CSS 문제나 위 표의 불안정 원인을 확인함
5. 원인을 고치거나 그 기준 이미지 하나를 업데이트함. 두 가지를 같은 커밋에서 하지 않음

자주 묻는 질문

기준 이미지는 어디에 저장되나요?

기본값은 테스트 파일 옆의 폴더이며, 폴더 이름은 테스트 파일 이름에 -snapshots 접미사를 붙인 것입니다. snapshotPathTemplate 설정 옵션으로 위치를 바꿀 수 있습니다.

Playwright Test 없이도 스크린샷을 비교할 수 있나요?

가능합니다. 어떤 도구로든 캡처하고 이미지 차이 도구로 파일을 비교하면 됩니다. Playwright Test는 이 비교 위에 재시도, 마스킹, 리포트 기능을 추가합니다.

스크린샷 테스트를 풀 리퀘스트마다 실행해야 하나요?

컴포넌트 단위 검증은 보통 그렇게 합니다. 전체 페이지 스위트가 파이프라인을 느리게 만들면 일정에 따라 실행하거나 릴리스 전에 실행합니다.

코드 변경이 없는데 로컬에서는 통과하고 CI에서는 실패하는 이유는 무엇인가요?

두 환경이 텍스트를 다르게 렌더링하기 때문입니다. macOS와 Linux는 폰트, 안티앨리어싱, 브라우저 빌드가 모두 다를 수 있습니다. 로컬과 CI에서 같은 Docker 이미지로 스위트를 실행합니다.

새 스위트는 프로젝트를 몇 개로 시작해야 하나요?

하나입니다. 데스크톱 프로젝트 하나로 시작해서 기준 이미지가 일주일에서 2주 동안 계속 통과할 때까지 유지합니다. 그다음 모바일 프로젝트를 추가합니다. 모바일 레이아웃이 가장 많이 다르기 때문입니다. 두 번째 데스크톱 브라우저는 마지막에 추가하며, 사용자가 브라우저별 레이아웃 버그를 보고할 때만 추가합니다.

로그인 뒤의 페이지도 테스트할 수 있나요?

가능합니다. 설정 프로젝트에서 한 번 로그인하고 storageState로 세션을 저장한 뒤, 시각 프로젝트에서 그 파일을 불러옵니다. 이름과 숫자가 매번 같도록 고정된 데이터를 가진 전용 테스트 계정을 사용합니다.

기준 이미지를 Git LFS에 저장해야 하나요?

스위트가 이미지를 수백 개 가지고 있거나 PNG 파일이 자주 바뀌면 도움이 됩니다. 약 60개 파일 규모의 스위트라면 일반 Git으로 충분한 경우가 많습니다. 기준 이미지를 몇 달 동안 업데이트한 뒤 저장소 크기를 확인합니다.

참고 자료

• Playwright visual comparisons
• Playwright projects
• Playwright Docker images

코드 없이 웹사이트 스크린샷을 자동으로 찍으려면?

결과가 통과 또는 실패가 아니라 스크린샷 모음이라면, Temposhot Website Capture가 Mac에서 URL 목록을 로컬로 실행합니다. 웹사이트 스크린샷 자동화나 Website Capture 빠른 시작을 참고합니다.