프런트엔드 개발을 위한 테스트 입문 - 프런트엔드 테스트 기초 지식부터 UI 컴포넌트 테스트 E2E 테스트 등 상황에 맞는 테스트 전략까지

지금이라도 알아두면 쓸데 있는 테스트 자동화 전략

최신 웹 애플리케이션에서는 품질과 유지보수성을 위해 테스트 자동화가 중요하지만, 테스트 코드를 작성해본 경험이 없어 테스트 코드 작성을 어려워하는 개발자가 많다. 이 책은 테스트 코드를 처음 작성하는 프런트엔드 개발자를 대상으로, 기본적인 테스트 코드 작성법은 물론 상황별 테스트 코드 작성법, 다양한 도구 사용법까지 풍부한 예제와 함께 설명한다. 특히 타입스크립트, Next.js로 만든 예제를 포함하고 있어 최신 실무 지식과 노하우를 익힐 수 있다. 한국어판 부록으로 깃허브 액션에서의 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쪽)