이용안내는 화면 캡처 수십 장으로 설명하는 문서라, 화면을 고칠 때마다 통째로 낡습니다. 9월에 두 번, 이용안내만 34장을 다시 찍었어요. 촬영은 Playwright 스펙이 대신 하지만 자동화되는 건 셔터뿐이고 무엇을 찍을지·무엇이 찍히면 안 되는지는 사람이 정해야 했습니다. 사용자 안내에 싣는 역할을 넷으로 줄인 기준, 디버그 툴바가 그림에 찍힌 사고, 앞 촬영이 남긴 데이터가 다음 캡처를 오염시킨 일을 정리합니다.
Playwright 전체 스위트가 235 통과 · 25 실패 · 11 skip인 채로 한동안 있었습니다. 25건을 하나씩 열어 갈라 보니 코드 회귀 1 · 데이터 없음 4 · 나머지는 화면과 데이터를 못 따라간 낡은 스펙이었어요. 빨간불이 오래 쌓이면 진짜 회귀가 그 안에 묻힙니다. 같은 날 선택자가 사라져 영영 건너뛰던 스펙, 저장한 뒤에 건너뛰어 데이터를 남기던 스펙도 함께 고쳐, 다시 돌린 274건이 실패 0으로 끝났습니다.
엑셀 재적재 한 번에 dcat:Catalog의 pk가 35에서 5로 밀렸고, 그 번호를 URL에 박아둔 스펙 11개가 동시에 빨개졌습니다. pk를 URI 조회로 바꾸고, 무엇이 밀리고 무엇이 안 밀리는지 선을 그었습니다. 덤으로 타임아웃 때 원복이 같이 죽어 dev DB가 며칠간 어긋나 있던 것도 잡았어요.
납품 문서의 기능목록 엑셀을 JSON으로 뽑아 메뉴 136종을 전부 열어보는 Playwright 스윕을 만들었습니다. 설정을 용도별 3종으로 나눈 이유, SQLite 때문에 워커를 1로 고정한 이유, 그리고 확인 못 한 항목을 스킵으로 남겨둔 게 옳은 선택이었는지까지 적었습니다.
Tailwind 메이저 업그레이드를 앞두고 시각 회귀를 잡기 위해 Playwright 기반 페이지 캡쳐 스크립트를 만든 경위와, 그 과정에서 만난 작은 어려움들을 정리합니다.
포트폴리오용 커뮤니티 서비스에서 "비어 보이지 않게, 가짜 같지 않게" 더미 데이터를 만든 과정을 정리합니다. 페이지네이션 검증과 작성자 분산이 핵심이었습니다.
인프런 "실무에 바로 적용하는 스토리북과 UI 테스트"를 듣고 meta/story 문법, Atomic 컴포넌트 조합, Decorator, 네 가지 UI 테스트를 정리했습니다. 강의 자료에서 발견한 구식 API와 안 도는 코드도 함께 적어 두었고, 마지막에는 이걸 다 배우고도 내 프로젝트에는 Storybook을 도입하지 않은 이유를 정리했습니다.
TDD, 스냅샷 테스트, 스토리북 기반 시각적 회귀 테스트, Cypress E2E, 테스트 더블까지 2부에서 다룬 내용을 주제별로 압축했습니다. 그리고 1년 반이 지난 지금, 이 중 실제로 실무와 사이드 프로젝트에 남은 것은 무엇이고 끝내 쓰지 못한 것은 무엇인지 정직하게 결산했습니다.
Vitest와 Testing Library로 단위 테스트부터 통합 테스트까지 다루는 강의를 들으며 정리한 내용을, 챕터 나열 대신 주제별 핵심으로 압축했습니다. 뒤이어 이 중 어떤 개념이 실제 프로젝트(Jest 테스트 복구, Playwright QA 스윕)에서 살아남았고 어떤 개념은 유지되지 못했는지 정직하게 결산했습니다. 강의 예제 자체에서 발견한 낡은 API와 깨지기 쉬운 코드도 함께 짚었습니다.
Next.js를 14.2에서 15.1로 올리는 커밋에 jest 의존성과 test 스크립트 삭제가 같이 실려 있습니다. 테스트 파일은 처음부터 0개였으니 지운 건 돌지 않는 러너뿐이었어요. 같은 주에 프런트엔드 테스트 강의를 정리해 블로그에 올리고 있었습니다. 그 어긋남을 그대로 적습니다.
프론트엔드 개발에서 테스트 주도 개발(TDD, Test-Driven Development)은 코드 작성 전에 테스트를 먼저 작성하여 애플리케이션의 기능과 동작을 검증하는 방법론입니다. TDD는 코드의 품질을 높이고, 버그를 줄이며, 유지보수를 용이하게 하는 데 도움이 됩니다. 프론트엔…
프론트엔드 개발에서 테스트 코드는 애플리케이션의 다양한 부분을 자동으로 검사하여 버그를 찾고, 기능이 예상대로 작동하는지 확인하는 데 중요합니다. 프론트엔드 테스트 코드는 주로 다음과 같은 종류로 나뉩니다: