「프론트엔드 테스트 제대로 하기」 시리즈의 10편입니다. 전체 목차 보기 · 용어집 “접근성 테스트"라고 하면 어떤 그림이 떠오르시나요? 전문 컨설팅을 의뢰하고, 별도의 검사 도구를 도입하고, 체크리스트 수백 개를 훑는… 그런 큰일처럼 느껴지기 쉽습니다. 그런데 놀랍게도, 접근성 검증의 절반은 컴포넌트 테스트를 “잘” 쓰는 것만으로 공짜로 따라옵니다. 이 글은 그 원리와 실전 방법입니다 — div 버튼 걸러내기, 아이콘 버튼에 이름 붙이기, 사라지는 포커스 지키기까지. ...
「프론트엔드 테스트 제대로 하기」 시리즈의 9편입니다. 전체 목차 보기 · 용어집 컴포넌트가 API를 부르기 시작하면 테스트가 흔들립니다. 서버가 느리면 같이 느려지고, 데이터가 바뀌면 깨지고, 오프라인이면 전멸이죠. MSW(Mock Service Worker) 는 네트워크 요청을 경계에서 가로채 준비된 응답을 돌려주는 도구로, 이 문제를 뿌리에서 해결합니다. 이 글 하나로 설치·핸들러·성공과 실패 시뮬레이션까지 정리해요. ...
「프론트엔드 테스트 제대로 하기」 시리즈의 8편입니다. 전체 목차 보기 · 용어집 버튼은 눌러봐야, 입력창은 타이핑해봐야 진짜 테스트예요. user-event는 Testing Library 가족 중 상호작용 재현을 맡는 도구입니다 — 클릭 한 번에도 포커스 이동과 키 이벤트 순서까지 실제 브라우저처럼 밟아서, “사용자가 하면 되는데 테스트에선 안 되는” 간극을 없애주죠. 이 글에서 타이핑·클릭 테스트를 처음부터 완성합니다. ...
「프론트엔드 테스트 제대로 하기」 시리즈의 7편입니다. 전체 목차 보기 · 용어집 Testing Library는 React를 비롯한 컴포넌트 테스트의 사실상 표준 도구입니다. 그런데 이 도구의 진짜 알맹이는 API가 아니라 철학 하나예요 — 컴포넌트 테스트에 들어서면 “클래스 이름으로 찾을까? 내부 state를 들여다볼까?” 하는 유혹이 생기는데, Testing Library는 단호하게 말합니다. 사용자가 하는 대로 하라. 이 글에서 그 철학이 무슨 뜻인지, 쿼리를 고르는 순서, 그리고 왜 이 방식이 접근성과 한 몸인지를 검색 컴포넌트를 직접 만들며 확인합니다. ...