본문으로 건너뛰기

5.3 인증과 storage state

매 test마다 UI login을 반복하면 느리고 authentication service에 부하를 줍니다. Setup project에서 한 번 로그인하고 context storage state를 저장해 재사용할 수 있습니다.

import { test as setup, expect } from '@playwright/test';

setup('authenticate', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('이메일').fill(process.env.E2E_USER!);
  await page.getByLabel('비밀번호').fill(process.env.E2E_PASSWORD!);
  await page.getByRole('button', { name: '로그인' }).click();
  await expect(page).toHaveURL('/dashboard');
  await page.context().storageState({ path: 'playwright/.auth/user.json' });
});

Configuration에서 setup dependency와 storage state를 연결합니다. Auth file에는 cookie와 token이 들어 있으므로 .gitignore에 추가하고 CI secret처럼 취급합니다.

재사용 범위​

모든 test가 하나의 server-side account를 수정하면 병렬 충돌이 생깁니다. Read-only test는 공유 state를 사용할 수 있지만 data mutation test는 worker별 account 또는 API로 만든 독립 user를 사용합니다.

Session 만료, MFA, role별 권한, logout 자체가 test 목적이면 저장 상태를 우회하지 말고 실제 flow를 시험합니다.

참고: Authentication

인증 전략 세 가지​

전략적합한 경우위험
모든 test가 같은 stateServer-side state를 바꾸지 않는 read-only suiteaccount collision
Worker별 account병렬 test가 독립 record를 수정account pool 관리
Test별 loginLogin 자체와 보안 흐름 검증느림, rate limit

Storage state 보안​

Auth state file은 cookie와 local storage token을 포함할 수 있습니다. playwright/.auth를 ignore하고 CI artifact에도 올리지 않습니다.

playwright/.auth/

만료와 refresh​

Setup project가 성공해도 token이 매우 짧게 만료되면 main suite 중간에 401이 발생합니다. Test duration, token lifetime, refresh flow를 함께 고려합니다. 무조건 새 login으로 우회하기보다 제품의 refresh behavior가 요구사항이면 별도 test합니다.

실습​

  1. Lab setup project가 auth state를 생성하게 합니다.
  2. State file 내용을 검토하되 commit하지 않습니다.
  3. 만료된 state를 주입해 login redirect를 확인합니다.
  4. Role별 admin/user state를 project로 분리합니다.