프론트엔드 테스트 제대로 하기 프론트엔드 테스트 제대로 하기 RSS 피드 구독

「프론트엔드 테스트 제대로 하기」 시리즈의 22편입니다. 전체 목차 보기 · 용어집 작은 앱 하나에 테스트를 한 겹씩 쌓으면 무엇이 되는지 — 이 글은 그 여정의 회고이자, 프론트엔드 테스트 전체의 지도입니다. ...

「프론트엔드 테스트 제대로 하기」 시리즈의 21편입니다. 전체 목차 보기 · 용어집 AI가 짠 코드는 빠르고, 돌아가고, 화면도 예쁩니다. 문제는 그럴듯하게 틀린다는 것이에요. ...

↻ 2026-10-02 업데이트 AI 에이전트가 받는 스냅샷 설명을 바로잡았습니다. 처음 실은 스냅샷은 테스트에서 쓰는 Playwright 기본 aria 스냅샷이었는데, Playwright MCP가 모델에게 건네는 건 mode: 'ai'로 찍은 스냅샷이라 모양이 다릅니다. 다시 찍어 보니 div 버튼도 이름 없는 generic으로 남아 번호(ref)로 누를 수 있었어요. 실습 저장소가 쓰던 1.61에서도 같았으니, 버전이 바뀐 게 아니라 처음부터 잘못 짚은 것입니다. 그래서 "스크린 리더 사용자가 못 쓰는 화면은 AI 에이전트도 못 쓴다"는 단정을 거두고, 에이전트 도구마다 받는 트리가 다르다는 내용으로 고쳤습니다. role과 이름을 챙기라는 결론은 그대로예요. 「프론트엔드 테스트 제대로 하기」 시리즈의 20편입니다. 전체 목차 보기 · 용어집 ...

「프론트엔드 테스트 제대로 하기」 시리즈의 19편입니다. 전체 목차 보기 · 용어집 AI(ChatGPT·Claude 같은 대형 언어 모델, LLM)에게 테스트를 짜달라고 하면 될까요? 됩니다. 다만 그대로 믿으면 안 돼요. AI는 그럴듯한 테스트를 몇 초 만에 뽑아주지만, 정작 중요한 경계·실패·접근성 케이스를 조용히 빼먹는 경향이 있거든요. 이 글은 AI를 테스트 작성의 조수로 제대로 부리는 법입니다 — 좋은 초안을 받는 요령부터, 받은 테스트가 진짜 일하는지 검증하는 체크리스트까지. ...

「프론트엔드 테스트 제대로 하기」 시리즈의 18편입니다. 전체 목차 보기 · 용어집 커버리지 리포트를 열면 숫자가 네 종류나 나옵니다 — Stmts, Branch, Funcs, Lines. 뭘 봐야 할까요? 이 글은 그 리포트를 읽는 법입니다: 어떤 숫자가 정직한지(스포일러: 브랜치), 빨간 줄에서 무엇을 채울지, 그리고 숫자가 못 보여주는 팀 건강은 어디서 볼지까지. ...

「프론트엔드 테스트 제대로 하기」 시리즈의 17편입니다. 전체 목차 보기 · 용어집 테스트는 '로컬에서 가끔 돌리는 것'일 때는 힘이 없습니다. PR마다 자동으로 도는 관문이 될 때 비로소 팀을 지키죠. 이 글은 GitHub Actions로 그 관문 — 단위 테스트·E2E·접근성 검사가 통과해야만 코드가 합쳐지는 머지 게이트 — 를 워크플로우 파일 하나로 세우는 방법입니다. CI가 처음이어도 됩니다. 용어부터 3분 정리하고 시작해요. ...

「프론트엔드 테스트 제대로 하기」 시리즈의 16편입니다. 전체 목차 보기 · 용어집 모든 테스트가 초록불인데 화면이 깨진 적, 있으시죠? 로직은 멀쩡한데 CSS 하나가 레이아웃을 무너뜨린 경우요. 시각적 회귀 테스트는 기준 스크린샷(baseline)을 저장해두고 픽셀을 비교해서, 이런 "눈으로 봐야 아는 회귀"를 자동으로 잡는 기법입니다. Playwright에 내장돼 있어 한 줄이면 시작해요 — 대신 흔들리지 않게 찍는 요령과 환경 차이라는 복병까지, 이 글에서 다 짚습니다. ...

「프론트엔드 테스트 제대로 하기」 시리즈의 15편입니다. 전체 목차 보기 · 용어집 버튼 하나에 이름이 붙었는지는 그 버튼만 봐도 압니다. 그런데 글씨 색이 배경과 충분히 대비되는지, 페이지에 언어가 지정됐는지, id가 중복되진 않았는지는 요소 하나만 봐선 알 수 없어요. 화면 전체를, 그것도 실제로 그려진 상태로 봐야 하죠. 이건 사람이 매번 눈으로 하기엔 지치는 일이고, 그래서 자동 검사 엔진이 필요합니다. ...

「프론트엔드 테스트 제대로 하기」 시리즈의 14편입니다. 전체 목차 보기 · 용어집 "내 컴퓨터에선 되는데 CI에선 빨간불." E2E를 운영하는 모든 개발자의 숙제이자, console.log를 도배하게 만드는 주범이죠. Playwright에는 이 미스터리를 증거 기반으로 푸는 도구가 셋 내장돼 있습니다 — 실패 순간을 통째로 되감는 트레이스, 시간여행하듯 보는 UI 모드, 그리고 신호로 쓰는 리트라이. 이 글에서 셋 다 챙깁니다. ...

「프론트엔드 테스트 제대로 하기」 시리즈의 13편입니다. 전체 목차 보기 · 용어집 E2E 테스트가 열 개를 넘어가면 두 가지가 아파옵니다. 테스트마다 복붙되는 준비 코드, 그리고 순서대로 도느라 느려지는 스위트. Playwright의 픽스처(반복 준비를 테스트에 주입하는 장치)와 병렬 실행이 이 둘을 한 번에 해결합니다 — 이 글에서 커스텀 픽스처, 인증 재사용(storageState), 병렬 안전 수칙까지 정리해요. ...