10.5 Test Pyramid와 Contract 경계
Playwright가 browser와 API를 모두 다룰 수 있다고 해서 모든 검증을 E2E로 만들 필요는 없습니다. 빠르고 좁은 test와 느리지만 통합 범위가 넓은 test를 요구사항 위험에 맞게 배치합니다.
Layer별 책임
| Layer | 검증할 것 | 피할 것 |
|---|---|---|
| Unit | pure logic, validation rule | browser rendering |
| Component | state별 UI rendering, interaction | 실제 전체 backend |
| API/contract | schema, permission, state transition | pixel layout |
| Browser integration | frontend-backend 경계, navigation | 모든 edge data 조합 |
| E2E | 핵심 사용자 journey와 배포 confidence | 세부 구현 branch 전부 |
같은 요구사항을 나누는 예
“사용자가 CSV를 export한다”는 하나의 문장이지만 다음처럼 분해합니다.
- Unit: filter option을 query parameter로 변환
- API: export endpoint authorization과 CSV schema
- Browser: filter를 선택하고 download가 시작되는지
- E2E: 실제 data가 포함된 파일을 받아 핵심 row를 확인
Mock의 신뢰 비용
await page.route('**/api/orders', route => route.fulfill({
json: [{ id: 'ORDER-1', status: 'paid' }],
}));
빠르고 deterministic하지만 backend schema가 바뀌어도 mock은 그대로 통과할 수 있습니다. Contract test 또는 소수의 real-backend E2E가 이 위험을 보완해야 합니다.
선택 질문
- 이 실패가 어느 component의 책임인지 빠르게 알 수 있는가?
- 같은 behavior를 더 낮은 layer에서 빠르게 검증할 수 있는가?
- Mock과 real implementation 사이 drift를 누가 감지하는가?
- 이 test는 PR마다 필요한가, scheduled run이 적합한가?
- 실패했을 때 release를 막아야 하는가?
Component testing 주의
Playwright component testing의 지원 상태와 framework integration은 변할 수 있습니다. 도입 전 현재 공식 문서의 안정성, bundler, CI 지원과 upgrade cost를 확인합니다. Product가 이미 Storybook 같은 component harness를 사용한다면 기존 ecosystem과 비교합니다.
Suite budget
각 test group에 latency, flake rate, ownership, artifact cost budget을 둡니다. Test 수가 아니라 release confidence 대비 운영 비용을 봅니다.
실습
- Todo Lab 요구사항 10개를 test layer에 배치합니다.
- Network mock test와 real server test를 한 쌍으로 만듭니다.
- E2E에서 과도한 data 조합을 API parameterized test로 이동합니다.
- Smoke suite의 최대 실행 시간과 허용 flake rate를 문서화합니다.