「프론트엔드 테스트 제대로 하기」 시리즈의 16편입니다. 전체 목차 보기 · 용어집 모든 테스트가 초록불인데 화면이 깨진 적, 있으시죠? 로직은 멀쩡한데 CSS 하나가 레이아웃을 무너뜨린 경우요. 시각적 회귀 테스트는 기준 스크린샷(baseline)을 저장해두고 픽셀을 비교해서, 이런 “눈으로 봐야 아는 회귀"를 자동으로 잡는 기법입니다. Playwright에 내장돼 있어 한 줄이면 시작해요 — 대신 흔들리지 않게 찍는 요령과 환경 차이라는 복병까지, 이 글에서 다 짚습니다. ...
「프론트엔드 테스트 제대로 하기」 시리즈의 15편입니다. 전체 목차 보기 · 용어집 버튼 하나에 이름이 붙었는지는 그 버튼만 봐도 압니다. 그런데 글씨 색이 배경과 충분히 대비되는지, 페이지에 언어가 지정됐는지, id가 중복되진 않았는지는 요소 하나만 봐선 알 수 없어요. 화면 전체를, 그것도 실제로 그려진 상태로 봐야 하죠. 이건 사람이 매번 눈으로 하기엔 지치는 일이고, 그래서 자동 검사 엔진이 필요합니다. ...
「프론트엔드 테스트 제대로 하기」 시리즈의 14편입니다. 전체 목차 보기 · 용어집 “내 컴퓨터에선 되는데 CI에선 빨간불.” E2E를 운영하는 모든 개발자의 숙제이자, console.log를 도배하게 만드는 주범이죠. Playwright에는 이 미스터리를 증거 기반으로 푸는 도구가 셋 내장돼 있습니다 — 실패 순간을 통째로 되감는 트레이스, 시간여행하듯 보는 UI 모드, 그리고 신호로 쓰는 리트라이. 이 글에서 셋 다 챙깁니다. ...
「프론트엔드 테스트 제대로 하기」 시리즈의 13편입니다. 전체 목차 보기 · 용어집 E2E 테스트가 열 개를 넘어가면 두 가지가 아파옵니다. 테스트마다 복붙되는 준비 코드, 그리고 순서대로 도느라 느려지는 스위트. Playwright의 픽스처(반복 준비를 테스트에 주입하는 장치)와 병렬 실행이 이 둘을 한 번에 해결합니다 — 이 글에서 커스텀 픽스처, 인증 재사용(storageState), 병렬 안전 수칙까지 정리해요. ...
「프론트엔드 테스트 제대로 하기」 시리즈의 12편입니다. 전체 목차 보기 · 용어집 flaky 테스트 — 코드는 그대로인데 어떤 날은 통과하고 어떤 날은 실패하는 테스트. E2E를 처음 도입한 팀이 가장 먼저 앓는 병이고, 방치하면 “또 걔야? 그냥 다시 돌려"라는 무서운 문화로 이어집니다. 다행히 원인은 대부분 하나예요: 너무 일찍, 혹은 잘못된 방법으로 요소를 찾는 것. 이 글에서 Playwright의 로케이터와 auto-wait로 그 뿌리를 뽑습니다. ...
「프론트엔드 테스트 제대로 하기」 시리즈의 11편입니다. 전체 목차 보기 · 용어집 Playwright는 진짜 브라우저(크로미움·파이어폭스·웹킷)를 코드로 조종하는 E2E 테스트 도구입니다. E2E(End-to-End)는 이름 그대로 끝에서 끝까지 — 사용자가 접속해서 검색하고 결과를 보는 흐름 전체를 실제 브라우저에서 재현하는 테스트고요. 이 글에서 설치부터 첫 시나리오 통과까지 한 번에 갑니다. ...
「프론트엔드 테스트 제대로 하기」 시리즈의 부록입니다. 본문을 읽다가 낯선 용어를 만나면 언제든 이 페이지로 돌아오세요. 전체 목차 보기 프론트엔드 테스트를 배우다 보면 낯선 용어가 쏟아집니다. mock과 stub은 뭐가 다른지, getBy와 queryBy는 언제 갈리는지, 커버리지 숫자는 왜 그대로 믿으면 안 된다는 건지 — 그런 용어들을 이 페이지 하나에 전부 모았습니다. 항목마다 “이게 뭔지"에서 멈추지 않고 “왜 필요한지”, “언제 쓰는지"까지 담았어요. ...
「프론트엔드 테스트 제대로 하기」 시리즈의 1편입니다. 전체 목차 보기 · 용어집 “테스트요? 지금도 잘 돌아가는데요.” 한 번쯤 해봤거나, 들어봤을 말이죠. 저도 오랫동안 그랬습니다. 눈으로 보고, 손으로 클릭해보고, “어 되네” 하면 그걸로 충분하다고 생각했어요. 그런데 기능이 늘고, 코드를 고칠 때마다 “이거 고치면 저쪽이 안 터지나?” 하는 불안이 스멀스멀 올라오기 시작하면, 그때가 바로 테스트가 필요해지는 순간입니다. ...