Capstone: 100개 테스트 스위트, 엔드‑투‑엔드 (Playwright + TypeScript, 26장)
출처: Dev.to
모든 것이 하나로 모이는 순간입니다. 강의 전체에 걸쳐 우리는 계층화된 Playwright TypeScript 프레임워크—fixture, Page Object, API + UI + 통합 테스트, CI, 리포팅—를 실제 Docker 기반 애플리케이션에 적용해 구축했습니다. 이 캡스톤 프로젝트가 전체를 완성합니다: 엔드‑투‑엔드 여정, 폭넓은 커버리지, 그리고 녹색, 빠르고, 결정론적인 테스트 스위트.
── Run summary ───────────────────────────────
result: passed
tests: 100 (✓ 100 ✘ 0 ⤿ flaky 0 – skipped 0)
projects: setup 1 api 66 ui 33Enter fullscreen mode
Exit fullscreen mode
이 챕터의 코드는 레포지토리에서 ch-26 태그로 확인할 수 있습니다:
https://github.com/aktibaba/playwright-qa-course.
엔드‑투‑엔드 여정
헤드라인 테스트는 전체 제품을 사용자가 사용하는 방식대로 검증합니다—그리고 각 테스트는 새로운 아이덴티티를 갖기 때문에 완전히 격리됩니다:
test("a new user signs up, publishes an article, and sees it on their profile", async ({
signUpPage, articleEditorPage, articlePage, page,
}) => {
const username = uniqueId("author").replace(/-/g, "");
await signUpPage.signUp({ username, email: `${username}@test.io`, password: "Password123!" });
const title = `Capstone article ${Date.now()}`;
await articleEditorPage.publishArticle({ title, description: "…", body: "…", tags: "capstone" });
await articlePage.expectTitle(title);
await page.goto(`/#/profile/${username}`);
await expect(page.getByRole("heading", { name: title })).toBeVisible();
});Enter fullscreen mode
Exit fullscreen mode
회원가입 → 저자 → 보기 → 프로필까지, 모두 UI를 통해 진행되며 우리가 만든 모든 Page Object와 fixture를 재사용합니다. 이렇게 풍부한 여정을 구현하는 데 드는 추가 비용은 읽기 쉬운 몇 줄에 불과합니다.
100개의 테스트가 다루는 영역
API (66): 기사 CRUD, 댓글, 즐겨찾기, 팔로우, 프로필, 태그, 페이지네이션, 개인화 피드, 인증 & 세션, 검증, 권한 부여 등.
UI (33): 로케이터 & 어설션, 로그인/회원가입/로그아웃, 기사 편집기, 댓글, 설정, 프로필 & 피드, 태그 필터링, 네트워크 모킹, 시각적 회귀, 접근성, 그리고 엔드‑투‑엔드 여정.
교차 영역: API를 통한 시드 / UI 검증, storageState 인증, 샤드된 CI, 커스텀 리포터, 전역에 걸친 고유 데이터 격리.
스위트가 발견한 버그
실제 규모에서 정직하게 실행했을 때, 스위트는 좋은 테스트가 해야 할 일을 수행했습니다—애플리케이션에서 7개의 실제 버그를 찾아냈으며 모두 sut/ 디렉터리에서 수정되었습니다:
createArticle에서tagList가 누락되면 크래시가 발생했습니다.- null‑author 레이스(
setAuthor를 await 하지 않음) 때문에 부하가 걸리면GET /articles가 크래시되었습니다. slug가 고유하지 않아 중복 슬러그가 발생하고 즐겨찾기 기본키 충돌이 일어났습니다.offset페이지네이션이 RealWorld 계약(offset * limit)을 위반했습니다.- UI 전반에 걸친 WCAG‑AA 색 대비 실패가 있었습니다.
updateUser가 모든 프로필 업데이트 시500오류를 반환했으며(||가 항상 true), 비밀번호가 덮어써질 위험이 있었습니다.- 잘못된 토큰이 401 대신 500을 반환했습니다.
프레임워크의 진정한 가치는 “테스트가 통과했는가?”를 넘어, 스위트가 빨간색으로 변했을 때 신뢰할 수 있다는 점이며, UI만으로는 절대 잡히지 않을 문제들을 포착한다는 점입니다.
다음 단계
- 더 많은 브라우저/디바이스 — WebKit과 Firefox 프로젝트를 추가하고 모바일 뷰포트를 지원합니다.
- CI에서 시각적 커버리지 — Playwright Docker 이미지에서 Linux 베이스라인을 생성합니다.
- 데이터 & 트렌드 —
json/blob결과를 대시보드로 전송하고, 플래키 비율을 시간에 따라 추적합니다(Chapter 25). - 계약 테스트 — 공개된 RealWorld OpenAPI 스펙에 맞춰 API를 검증합니다.
- 성능 예산 — 핵심 요청이 임계값을 초과하면 테스트를 실패하도록 합니다.
프레임워크는 기반이며, 여기서 제시된 작업들은 전면적인 재작성 없이도 오후 몇 시간 안에 구현할 수 있습니다—왜냐하면 **아키텍처(Part 2)**가 확장을 염두에 두고 설계되었기 때문입니다.
감사 인사
이것이 바로 코스 전체입니다: “왜 프레임워크가 필요한가”에서 시작해, CI에서 실행되고 실제 애플리케이션을 개선하기까지 이르는 프로덕션 급 100개의 테스트, API + UI 스위트를 완성했습니다. 레포를 클론하고(repo), 원하는 ch‑NN 태그를 확인한 뒤 여러분만의 것으로 만들어 보세요.
이 시리즈가 도움이 되었다면 레포에 ⭐를 눌러주시고, 여러분이 만든 프로젝트를 알려 주세요. 즐거운 테스트 되세요. 🎭