수많은 테스트 방법 중에 나에게 맞는 테스트 방법을 찾아 업무 효율을 높이자 최근 몇 년간 강력한 라이브러리와 프레임워크의 등장으로 프런트엔드 개발에서는 많은 변화가 있었다. 싱글 페이지 애플리케이션을 필두로 한 모던 프런트엔드 기술들은 이미 많은 제품에 적용되어 사실상 표준으로 자리잡았다. 개발 환경의 변화와는 대조적으로 테스트 코드 작성을 어려워하는 개발자가 많다. 게다가 프런트엔드 테스트는 UI 컴포넌트 테스트, 시각적 회귀 테스트, 스토리북, E2E 테스트 등 테스트 방법이 너무 많아서 언제, 어떤 테스트가 필요한지 판단하는 것이 쉽지 않다. 어떤 상황에서나 정답인 은빛 총알은 없다. 각자의 상황에 맞는 도구를 선택해서 테스트해야 한다. 프런트엔드에는 테스트 방법이 많은 만큼 최적의 방법을 고를 수 있다. 이 책은 가장 주목받는 프레임워크인 Next.js와 타입스크립트를 통해 최신 개발 환경을 살펴보고 어떤 상황에서 어떤 테스트를 해야 하는지 살펴본다. 1~4장에서는 테스트 코드를 처음 작성하는 개발자가 대상이다. 1장에서는 테스트를 작성해야 하는 이유를, 2장에서는 테스트 범위와 목적을 다뤄 프런트엔드 테스트의 전체적인 흐름을 이해할 수 있도록 돕는다. 3장과 4장은 본격적으로 실습에 들어가기 앞서 단위 테스트와 목 객체를 활용한 테스트를 심도 깊게 다룬다. 5~10장에서는 리액트와 Next.js 예제를 활용한 모던 프런트엔드 기술을 사용한다. 5장에서는 UI 컴포넌트를 테스트할 때 중점을 둬야 하는 부분을 살펴보며, 6장에서는 구현 코드가 얼마나 테스트됐는지 측정하는 커버리지 리포트를 작성해본다. 7장에서는 본격적으로 Next.js로 만든 애플리케이션 예제를 통해 실무에 가까운 테스트를 한다. 8장에서는 협업 시 능률이 높아질 수 있도록 UI 컴포넌트 공유를 돕는 UI 컴포넌트 탐색기인 스토리북에 대해 살펴본다. 9장에서는 UI 컴포넌트에 시각적 회귀 테스트를 실시하면서 시각적 회귀 테스트의 중요성을, 10장에서는 실제 애플리케이션에 가까운 테스트가 가능한 E2E 테스트를 알아본다. 마지막으로 한국 독자를 위해 깃허브 액션에서 UI 컴포넌트 테스트 및 E2E 테스트하는 방법을 부록으로 수록했다. 테스트 코드는 비용을 절약할 수 있는 것은 물론 버그를 사전에 발견해 코드 품질을 높일 수 있고, 새로 들어온 팀원에게 보여줄 사양서로 활용할 수도 있으며, 리팩터링 시 초보적인 실수를 줄이는 용도로 사용할 수도 있다. 테스트 코드 작성을 하면서 얻을 수 있는 많은 장점에도 테스트 코드를 미루고 있거나 어렵게 느껴진다면 이 책이 프런트엔드 테스트의 좋은 지침서가 될 것이다. 이 책을 통해 자신감 있게 테스트 코드를 작성할 수 있게 되기를 바란다. 주요 내용 ● 테스트의 필요성과 프런트엔드 테스트의 흐름 ● E2E 테스트, 단위 테스트, UI 컴포넌트 테스트 등 적재적소의 테스트 방법 ● 제스트, 리액트, reg-suit 등 다양한 라이브러리와 도구 ● 목 객체를 활용한 실패 재현 테스트 ● UI 컴포넌트를 위한 스토리북 사용법 ● 깃허브 액션에서의 UI 컴포넌트 테스트와 E2E 테스트

옮긴이 머리말 xiii 베타리더 후기 xv 시작하며 xvi 이 책에 대하여 xvii CHAPTER 1 테스트 목적과 장애물 1 1.1 이 책의 구성 1 1.2 테스트를 작성해야 하는 이유 4 1.3 테스트 작성의 장벽 9 CHAPTER 2 테스트 방법과 테스트 전략 13 2.1 테스트 범위와 목적 13 2.2 프런트엔드 테스트의 범위 15 2.3 프런트엔드 테스트의 목적 18 2.4 테스트 전략 모델 21 2.5 테스트 전략 계획 23 CHAPTER 3 처음 시작하는 단위 테스트 27 3.1 환경 설정 27 3.2 테스트 구성 요소 28 3.3 테스트 실행 방법 31 3.4 조건 분기 35 3.5 에지 케이스와 예외 처리 37 3.6 용도별 매처 43 3.7 비동기 처리 테스트 48 CHAPTER 4 목 객체 53 4.1 목 객체를 사용하는 이유 53 4.2 목 모듈을 활용한 스텁 55 4.3 웹 API 목 객체 기초 59 4.4 웹 API 목 객체 생성 함수 64 4.5 목 함수를 사용하는 스파이 68 4.6 웹 API 목 객체의 세부 사항 72 4.7 현재 시각에 의존하는 테스트 75 CHAPTER 5 UI 컴포넌트 테스트 79 5.1 UI 컴포넌트 테스트 기초 지식 79 5.2 라이브러리 설치 82 5.3 처음 시작하는 UI 컴포넌트 테스트 84 5.4 아이템 목록 UI 컴포넌트 테스트 89 5.5 인터랙티브 UI 컴포넌트 테스트 94 5.6 유틸리티 함수를 활용한 테스트 101 5.7 비동기 처리가 포함된 UI 컴포넌트 테스트 108 5.8 UI 컴포넌트 스냅숏 테스트 114 5.9 암묵적 역할과 접근 가능한 이름 118 CHAPTER 6 커버리지 리포트 읽기 125 6.1 커버리지 리포트 개요 125 6.2 커버리지 리포트 읽기 127 6.3 커스텀 리포터 132 CHAPTER 7 웹 애플리케이션 통합 테스트 135 7.1 Next.js 애플리케이션 개발과 통합 테스트 135 7.2 React Context와 통합 테스트 137 7.3 Next.js 라우터와 렌더링 통합 테스트 141 7.4 Next.js 라우터와 입력 통합 테스트 145 7.5 React Hook Form으로 폼 쉽게 다루기 149 7.6 폼 유효성 검사 테스트 151 7.7 웹 API 응답을 목 객체화하는 MSW 159 7.8 웹 API 통합 테스트 161 7.9 이미지 업로드 통합 테스트 167 CHAPTER 8 UI 컴포넌트 탐색기 175 8.1 스토리북 기초 175 8.2 스토리북 필수 애드온 180 8.3 Context API에 의존하는 스토리 등록 185 8.4 웹 API에 의존하는 스토리 등록 188 8.5 Next.js Router에 의존하는 스토리 등록 192 8.6 play function을 활용한 인터랙션 테스트 193 8.7 addon-a11y를 활용한 접근성 테스트 198 8.8 스토리북 테스트 러너 202 8.9 스토리를 통합 테스트에 재사용하기 207 CHAPTER 9 시각적 회귀 테스트 211 9.1 시각적 회귀 테스트의 필요성 211 9.2 reg-cli로 이미지 비교하기 214 9.3 스토리캡 도입 218 9.4 reg-suit 도입하기 222 9.5 외부 스토리지 서비스 설정 228 9.6 깃허브 액션에 reg-suit 연동하기 232 9.7 시각적 회귀 테스트를 활용한 적극적 리팩터링 236 CHAPTER 10 E2E 테스트 239 10.1 E2E 테스트란 239 10.2 플레이라이트 설치 및 기초 242 10.3 테스트할 애플리케이션 246 10.4 개발 환경에서 E2E 테스트 실행하기 250 10.5 프리즈마를 활용한 테스트 254 10.6 로그인 기능 E2E 테스트 259 10.7 프로필 기능 E2E 테스트 263 10.8 Like 기능 E2E 테스트 266 10.9 신규 작성 페이지 E2E 테스트 269 10.10 기사 편집 페이지 E2E 테스트 272 10.11 게재된 기사 목록 페이지 E2E 테스트 275 10.12 불안정한 테스트 대처 방법 278 APPENDIX A 한국어판 부록: 깃허브 액션에서 UI 컴포넌트 테스트 실행하기 281 A.1 깃허브 액션 핸즈온 281 A.2 워크플로 파일 작성법 288 A.3 작업을 병렬처리해서 워크플로 최적화하기 291 APPENDIX B 한국어판 부록: 깃허브 액션에서 E2E 테스트 실행하기 299 B.1 깃허브 액션에서 E2E 테스트 실행하기 299 B.2 도커파일 작성법 301 B.3 도커 컴포즈 파일 작성법 304 찾아보기 310

코드 수정은 새로운 기능을 개발할 때만 필요한 것이 아니다. 모던 프런트엔드 개발은 수많은 라이브러리에 의존할 수밖에 없기 때문에 라이브러리를 업데이트할 때도 코드를 수정해야 한다. 물론 디펜다봇(Dependabot)을 사용하면 의존하는 라이브러리가 업데이트됐을 때 발생할 수 있는 취약성을 자동으로 검사해 풀 리퀘스트(pull request)를 만들어준다. 하지만 디펜다봇이 모든 취약성을 걸러낼 것이라고 생각해서는 안 된다. 작성해놓은 테스트 코드가 있다면 ‘마이너 업데이트는 테스트를 통과하면 병합(merge)할 수 있다’ 같은 원칙을 세워야 한다. (6쪽) 릴리스된 프로젝트에 테스트 코드가 없으면 리팩터링이 두려울 수 있다. 이때는 먼저 릴리스된 기능을 목록으로 정리해야 한다. 정리가 됐다면 변경 전후로 결함이 발생하지 않았는지 검증하는 회귀 테스트를 작성한다. 작성된 회귀 테스트가 있으면 자신감 있게 리팩터링을 시작할 수 있다. (23쪽) 테스트는 실제 실행 환경과 유사할수록 재현성이 높다. 하지만 재현성을 높이다 보면 실행 시간이 너무 많이 걸리거나 환경 구축이 어려워지는 경우가 있다. 대표적인 경우가 웹 API에서 취득한 데이터를 다뤄야 할 때, 웹 API에서 데이터를 취득하면 네트워크 오류 같은 이유로 실패할 때가 있다. 웹 API를 사용하면 ‘성공하는 경우’뿐만 아니라 ‘실패하는 경우’도 테스트해야 한다. / 성공하는 경우는 실제 웹 API 서버를 테스트 환경과 연동할 수 있다면 테스트할 수 있다. 실패하는 경우를 웹 API 서버에 테스트하는 코드를 추가하는 것은 옳지 않다. 게다가 외부 서비스의 웹 API는 테스트용 구현을 추가하는 것이 애초에 불가능하다. (53쪽) 커버리지는 객관적인 측정이 가능한 정량 지표다. 프로젝트에 따라서 필수로 충족시켜야 하는 품질 기준으로 사용되기도 한다. 예를 들어 ‘분기 커버리지가 80% 이상이 아니면 CI를 통과하지 못한다’ 같은 파이프라인을 만드는 데 활용할 수 있다. (...) 커버리지는 특정 파일에 테스트를 추가해야 하는지 검토하는 계기로 활용된다. 또한, ESLint를 통과했지만 남은 중복 코드를 발견하는 데에도 유용하다. 릴리스 전에 충분히 테스트하지 않은 부분이 있는지 확인할 때 커버리지 리포트를 참고하는 것을 권장한다. (132쪽) 스토리북의 테스트 러너(test runner)는 스토리를 실행가능한 테스트로 변환한다. 테스트로 변환된 스토리는 제스트와 플레이라이트에서 실행된다. 이 기능을 활용해서 스토리북에 스모크 테스트(smoke test)는 물론 앞서 살펴본 play function이 정상적으로 종료됐는지와 접근성 위반 사항이 있는지도 테스트할 수 있어 UI 컴포넌트 테스트로도 활용할 수 있다. (202쪽) 프런트엔드에서 E2E 테스트는 브라우저를 사용할 수 있기 때문에 실제 애플리케이션에 가까운 테스트가 가능하다. 브라우저 고유의 API를 사용하는 상황이나 화면을 이동하며 테스트해야 하는 상황에 안성맞춤이다. (...) E2E 테스트는 무엇을 테스트할지 목적을 명확히 세우는 것이 가장 중요하다. 실제 애플리케이션은 데이터베이스 서버나 외부 저장소 서비스와 연결된다. E2E 테스트에서는 이 시스템들을 포함한 전체 구조에서 얼마나 실제와 유사한 상황을 재현할 것인지가 중요한 기준점이 된다. (239쪽)