1부 시작하기

1장 단위 테스트의 기초

1.1 누구에게나 처음은 있다
1.2 단위 테스트 정의
1.3 진입점과 종료점
1.4 종료점 유형
1.5 다른 종료점, 다른 기법
1.6 처음부터 테스트 코드 작성
1.7 좋은 단위 테스트의 특징
__1.7.1 좋은 단위 테스트란
__1.7.2 단위 테스트 체크리스트
1.8 통합 테스트
1.9 최종 정리
1.10 테스트 주도 개발
__1.10.1 TDD는 단위 테스트의 대체제가 아니다
__1.10.2 TDD를 잘하는 세 가지 핵심 기법
1.11 요약

2장 첫 번째 단위 테스트

2.1 제스트 소개
__2.1.1 환경 설정
__2.1.2 실습 폴더 생성
__2.1.3 제스트 설치
__2.1.4 테스트 파일 생성
__2.1.5 제스트 실행
2.2 라이브러리, 검증, 러너, 리포터
2.3 단위 테스트 프레임워크가 제공하는 기능
__2.3.1 xUnit 프레임워크
__2.3.2 xUnit, TAP, 제스트 구조
2.4 앞으로 이 책에서 주로 다루는 예제: 비밀번호 검증 프로젝트
2.5 verifyPassword( ) 함수의 첫 번째 테스트 코드
__2.5.1 준비-실행-검증 패턴
__2.5.2 테스트 코드 테스트
__2.5.3 USE 전략
__2.5.4 문자열 비교와 유지 보수성
__2.5.5 describe( ) 함수로 구역 나누기
__2.5.6 코드 구조로 알 수 있는 테스트 정보
__2.5.7 it( ) 함수
__2.5.8 두 가지 제스트 스타일
__2.5.9 verifyPassword( ) 함수 리팩터링
2.6 beforeEach( ) 함수 사용
__2.6.1 beforeEach( ) 함수와 스크롤 피로감
2.7 팩토리 함수 사용
__2.7.1 팩토리 함수로 beforeEach( ) 함수 완전히 대체
2.8 다시 test( ) 함수로 돌아가기
2.9 다양한 입력 값을 받는 테스트 리팩터링
2.10 예정된 오류가 발생하는지 확인
2.11 테스트 카테고리 설정
2.12 요약

2부 핵심 기술

3장 의존성 분리와 스텁

3.1 의존성 유형
3.2 스텁을 사용하는 이유
3.3 스텁을 사용하는 일반적인 설계 방식
__3.3.1 스텁으로 만든 시간을 매개변수로 주입
__3.3.2 의존성, 주입, 제어
3.4 함수를 이용한 주입 방법
__3.4.1 함수 주입
__3.4.2 부분 적용을 이용한 의존성 주입
3.5 모듈을 이용한 주입 방법
3.6 생성자 함수를 사용하여 객체 지향적으로 전환
3.7 객체 지향적으로 의존성을 주입하는 방법
__3.7.1 생성자 주입
__3.7.2 함수 대신 객체 주입
__3.7.3 공통 인터페이스 추출
3.8 요약

4장 모의 객체를 사용한 상호 작용 테스트

4.1 상호 작용 테스트, 목, 스텁
4.2 로거 함수에 의존
4.3 기본 스타일: 매개변수를 주입하는 방식으로 리팩터링
4.4 목과 스텁을 구분하는 것의 중요성
4.5 모듈 스타일의 목
__4.5.1 실제 예제 코드
__4.5.2 모듈 주입 방식으로 코드 리팩터링
__4.5.3 모듈 주입 방식을 이용한 테스트 예제
4.6 함수형 스타일에서 목
__4.6.1 커링 스타일 사용
__4.6.2 커링 없이 고차 함수 사용
4.7 객체 지향 스타일의 목
__4.7.1 의존성 주입을 위한 코드 리팩터링
__4.7.2 인터페이스 주입을 이용한 코드 리팩터링
4.8 복잡한 인터페이스 다루기
__4.8.1 복잡한 인터페이스 예
__4.8.2 복잡한 인터페이스를 사용하여 테스트 작성
__4.8.3 복잡한 인터페이스를 직접 사용할 때 단점
__4.8.4 인터페이스 분리 원칙
4.9 부분 모의 객체
__4.9.1 부분 모의 객체를 함수형 방식으로 풀어 보기
__4.9.2 부분 모의 객체를 객체 지향 방식으로 풀어 보기
4.10 요약

5장 격리 프레임워크

5.1 격리 프레임워크 정의
__5.1.1 선택하기: 느슨한 타입 대 정적 타입
5.2 동적으로 가짜 모듈 만들기
__5.2.1 제스트 API에 대해 알아 둘 점
__5.2.2 직접 의존성의 추상화 고민
5.3 함수형 스타일의 동적 목과 스텁
5.4 객체 지향 스타일의 동적 목과 스텁
__5.4.1 느슨한 타입의 프레임워크 사용
__5.4.2 타입스크립트에 적합한 프레임워크로 전환
5.5 동적 스텁 설정
__5.5.1 목과 스텁을 사용한 객제 지향 예제
__5.5.2 substitute.js를 사용한 스텁과 목
5.6 격리 프레임워크의 장점과 함정
__5.6.1 대부분의 경우 모의 객체가 필요하지 않다
__5.6.2 읽기 어려운 테스트 코드
__5.6.3 잘못된 대상 검증
__5.6.4 테스트당 하나 이상 목을 사용
__5.6.5 테스트의 과도한 명세화
5.7 요약

6장 비동기 코드 단위 테스트

6.1 비동기 데이터 가져오기
__6.1.1 통합 테스트를 이용한 첫 시도
__6.1.2 작업 기다리기
__6.1.3 async/await를 사용하는 통합 테스트
__6.1.4 통합 테스트의 어려움
6.2 코드를 단위 테스트에 적합하게 만들기
__6.2.1 진입점 분리 패턴
__6.2.2 어댑터 분리 패턴
6.3 타이머 다루기
__6.3.1 몽키 패칭으로 타이머를 스텁으로 만들기
__6.3.2 제스트로 setTimeout 대체
6.4 일반적인 이벤트 처리
__6.4.1 이벤트 이미터
__6.4.2 클릭 이벤트 처리 237
6.5 DOM 테스트 라이브러리 도입 240
6.6 요약 241

3부 테스트 코드

7장 신뢰할 수 있는 테스트

7.1 테스트를 신뢰할 수 있는지 판단하는 방법
7.2 테스트가 실패하는 이유
__7.2.1 프로덕션 코드에서 실제 버그가 발견된 경우
__7.2.2 테스트가 거짓 실패를 일으키는 경우
__7.2.3 기능 변경으로 테스트가 최신 상태가 아닌 경우
__7.2.4 테스트가 다른 테스트와 충돌하는 경우
__7.2.5 테스트가 불안정한 경우
7.3 단위 테스트에서 불필요한 로직 제거
__7.3.1 Assert 문에서 로직: 동적 기댓값 생성
__7.3.2 다른 형태의 로직 255
__7.3.3 로직이 더 많이 포함된 경우
7.4 테스트가 통과하더라도 끝이 아니다
__7.4.1 검증 부분이 없는 경우
__7.4.2 테스트를 이해할 수 없는 경우
__7.4.3 단위 테스트가 불안정한 통합 테스트와 섞여 있는 경우
__7.4.4 테스트가 여러 가지를 한꺼번에 검증하는 경우
__7.4.5 테스트가 자주 변경되는 경우
7.5 불안정한 테스트 다루기
__7.5.1 불안정한 테스트를 발견했을 때 할 수 있는 일
__7.5.2 상위 수준의 테스트에서 안전성을 유지하는 방법
7.6 요약

8장 유지 보수성

8.1 테스트 실패로 코드 변경
__8.1.1 테스트가 관련이 없거나 다른 테스트와 충돌하는 경우
__8.1.2 프로덕션 코드의 API 변경
__8.1.3 다른 테스트가 변경되었을 경우
8.2 유지 보수성을 높이는 리팩터링 방법
__8.2.1 private 또는 protected 메서드 사용하지 않기
__8.2.2 테스트에서도 DRY 원칙 고수
__8.2.3 초기화 함수를 사용하지 않기
__8.2.4 매개변수화된 테스트로 중복 코드 제거
8.3 과잉 명세된 테스트
__8.3.1 목을 사용한 내부 동작 과잉 명세
__8.3.2 결과와 순서를 지나치게 세밀하게 검증
8.4 요약

4부 디자인과 프로세스

9장 가독성

9.1 단위 테스트 이름 짓기
9.2 매직 넘버와 변수 이름
9.3 검증과 실행 단계 분리
9.4 초기화 및 설정 해제
9.5 요약

10장 더 나은 테스트 전략 수립

10.1 일반적인 테스트 유형과 수준
__10.1.1 테스트 평가 기준
__10.1.2 단위 테스트와 컴포넌트 테스트
__10.1.3 통합 테스트
__10.1.4 API 테스트
__10.1.5 E2E/UI 격리 테스트
__10.1.6 E2E/UI 시스템 테스트
10.2 각 테스트 수준마다 존재하는 안티 패턴
__10.2.1 E2E 테스트만 사용하는 안티 패턴
__10.2.2 저수준 테스트만 사용하는 안티 패턴
__10.2.3 저수준 테스트와 고수준 테스트의 단절
10.3 테스트 레시피 전략
__10.3.1 테스트 레시피 작성 방법
__10.3.2 언제 테스트 레시피를 사용해야 할까?
__10.3.3 테스트 레시피 작성 규칙
10.4 배포 파이프라인 관리
__10.4.1 배포 파이프라인 대 탐색 파이프라인
__10.4.2 테스트 계층 병렬화
10.5 요약

11장 조직 내 단위 테스트 도입

11.1 변화의 바람을 일으키는 과정
__11.1.1 까다로운 질문에 대비
__11.1.2 내부 설득: 변화에 찬성하는 사람과 반대하는 사람
__11.1.3 변화의 시작점을 찾아라
11.2 성공으로 가는 길
__11.2.1 게릴라 방식: 상향식
__11.2.2 경영진 설득하기: 하향식
__11.2.3 실험을 이용한 기회 창출
__11.2.4 외부 전문가에게 도움받기
__11.2.5 진행 상황 가시화
__11.2.6 구체적인 목표, 성과 지표, KPI 설정
__11.2.7 길 위의 돌부리
11.3 실패로 가는 길
__11.3.1 추진력 부족
__11.3.2 내부 지원 부족
__11.3.3 임시 구현과 첫인상
__11.3.4 팀원이 협조적이지 않을 때
11.4 변화에 영향을 미치는 요인
11.5 까다로운 질문과 답변
__11.5.1 단위 테스트가 현재 프로세스에서 얼마나 많은 시간을 차지할까?
__11.5.2 단위 테스트 때문에 QA 업무가 사라질까?
__11.5.3 단위 테스트가 정말로 도움이 된다는 증거가 있을까?
__11.5.4 테스트가 있음에도 왜 여전히 QA를 진행하면 버그가 발견될까?
__11.5.5 테스트 없는 코드가 너무 많은데 어디부터 시작해야 할까?
__11.5.6 소프트웨어와 하드웨어를 함께 개발할 때는 어떻게 해야 할까?
11.5.7 테스트 자체에 버그가 없다는 것을 어떻게 확인할 수 있을까?
11.5.8 디버거로 코드가 잘 작동하는 것을 확인했는데, 왜 테스트가 필요할까?
11.5.9 TDD는 어떻게 받아들여야 할까?
11.6 요약

12장 레거시 코드 다루기

12.1 어디에서부터 테스트를 시작해야 할까?
12.2 무엇을 선택할지 결정
__12.2.1 쉬운 것부터 시작했을 때 장단점
__12.2.2 어려운 것부터 시작했을 때 장단점
12.3 리팩터링 전에 통합 테스트 작성
__12.3.1 마이클 페더스 도서 참고
__12.3.2 CodeScene을 사용하여 프로덕션 코드 분석
12.4 요약

부록 A 함수와 모듈의 몽키 패칭

A.1 알아 두어야 할 점
A.2 함수와 전역 변수의 몽키 패칭과 그에 따른 잠재적 문제
__A.2.1 제스트를 사용한 몽키 패칭
__A.2.2 제스트 spy
__A.2.3 spyOn과 mockImplementation 함수 사용
A.3 제스트로 전체 모듈을 무시하는 것은 간단하다
A.4 각 테스트에서 모듈 동작을 페이크로 만들기
__A.4.1 기본 require.cache를 사용하여 모듈을 스텁으로 만들기
__A.4.2 제스트로 커스텀 모듈을 스텁으로 만드는 것은 복잡하다
__A.4.3 제스트로 직접 목 만들기
__A.4.4 사이넌으로 모듈을 스텁으로 만들기
__A.4.5 테스트 더블로 모듈을 스텁으로 만들기

부록 B 기본 환경 설정

B.1 깃 설치
B.2 노드 설치
B.3 예제 코드 내려받기
B.4 코드 에디터 설치 안내
B.5 예제 코드 실행 방법
__B.5.1 패키지 설치
__B.5.2 예제 실행

찾아보기