<b>1부. 더 큰 그림 </b><br/><br/>1장. 단위 테스트 목표<br/><br/>1.1 단위 테스트 현황 <br/>1.2 단위 테스트 목표 <br/>1.2.1 좋은 테스트와 좋지 않은 테스트를 가르는 요인<br/>1.3 테스트 스위트 품질 측정을 위한 커버리지 지표 <br/>1.3.1 코드 커버리지 지표에 대한 이해<br/>1.3.2 분기 커버리지 지표에 대한 이해<br/>1.3.3 커버리지 지표에 관한 문제점<br/>1.3.4 특정 커버리지 숫자를 목표로 하기<br/>1.4 무엇이 성공적인 테스트 스위트를 만드는가? <br/>1.4.1 개발 주기에 통합돼 있음<br/>1.4.2 코드베이스에서 가장 중요한 부분만을 대상으로 함<br/>1.4.3 최소 유지비로 최대 가치를 끌어냄<br/>1.5 이 책을 통해 배우는 것 <br/>요약 <br/><br/>2장. 단위 테스트란 무엇인가 <br/><br/>2.1 ‘단위 테스트’의 정의 <br/>2.1.1 격리 문제에 대한 런던파의 접근<br/>2.1.2 격리 문제에 대한 고전파의 접근<br/>2.2 단위 테스트의 런던파와 고전파 <br/>2.2.1 고전파와 런던파가 의존성을 다루는 방법<br/>2.3 고전파와 런던파 비교 <br/>2.3.1 한 번에 한 클래스만 테스트하기<br/>2.3.2 상호 연결된 클래스의 큰 그래프를 단위 테스트하기<br/>2.3.3 버그 위치 정확히 찾아내기<br/>2.3.4 고전파와 런던파 사이의 다른 차이점<br/>2.4 두 분파의 통합 테스트 <br/>2.4.1 통합 테스트의 일부인 엔드 투 엔드 테스트<br/>요약 <br/><br/>3장. 단위 테스트 구조 <br/><br/>3.1 단위 테스트를 구성하는 방법 <br/>3.1.1 AAA 패턴 사용<br/>3.1.2 여러 개의 준비, 실행, 검증 구절 피하기<br/>3.1.3 테스트 내 if 문 피하기<br/>3.1.4 각 구절은 얼마나 커야 하는가?<br/>3.1.5 검증 구절에는 검증문이 얼마나 있어야 하는가<br/>3.1.6 종료 단계는 어떤가<br/>3.1.7 테스트 대상 시스템 구별하기<br/>3.1.8 준비, 실행, 검증 주석 제거하기<br/>3.2 xUnit 테스트 프레임워크 살펴보기 <br/>3.3 테스트 간 테스트 픽스처 재사용 <br/>3.3.1 테스트 간의 높은 결합도는 안티 패턴이다<br/>3.3.2 테스트 가독성을 떨어뜨리는 생성자 사용<br/>3.3.3 더 나은 테스트 픽스처 재사용법<br/>3.4 단위 테스트 명명법 <br/>3.4.1 단위 테스트 명명 지침<br/>3.4.2 예제: 지침에 따른 테스트 이름 변경<br/>3.5 매개변수화된 테스트 리팩터링하기 <br/>3.5.1 매개변수화된 테스트를 위한 데이터 생성<br/>3.6 검증문 라이브러리를 사용한 테스트 가독성 향상 <br/>요약 <br/><br/><b>2부. 개발자에게 도움이 되는 테스트 만들기</b><br/><br/>4장. 좋은 단위 테스트의 4대 요소<br/><br/>4.1 좋은 단위 테스트의 4대 요소 자세히 살펴보기 <br/>4.1.1 첫 번째 요소: 회귀 방지<br/>4.1.2 두 번째 요소: 리팩터링 내성 <br/>4.1.3 무엇이 거짓 양성의 원인인가?<br/>4.1.4 구현 세부 사항 대신 최종 결과를 목표로 하기<br/>4.2 첫 번째 특성과 두 번째 특성 간의 본질적인 관계 <br/>4.2.1 테스트 정확도 극대화<br/>4.2.2 거짓 양성과 거짓 음성의 중요성: 역학 관계<br/>4.3 세 번째 요소와 네 번째 요소: 빠른 피드백과 유지 보수성 <br/>4.4 이상적인 테스트를 찾아서 <br/>4.4.1 이상적인 테스트를 만들 수 있는가?<br/>4.4.2 극단적인 사례 1: 엔드 투 엔드 테스트<br/>4.4.3 극단적인 사례 2: 간단한 테스트<br/>4.4.4 극단적인 사례 3: 깨지기 쉬운 테스트<br/>4.4.5 이상적인 테스트를 찾아서: 결론<br/>4.5 대중적인 테스트 자동화 개념 살펴보기 <br/>4.5.1 테스트 피라미드 분해<br/>4.5.2 블랙박스 테스트와 화이트박스 테스트 간의 선택<br/>요약 <br/><br/>5장. 목과 테스트 취약성<br/><br/>5.1 목과 스텁 구분 <br/>5.1.1 테스트 대역 유형<br/>5.1.2 도구로서의 목과 테스트 대역으로서의 목<br/>5.1.3 스텁으로 상호 작용을 검증하지 말라<br/>5.1.4 목과 스텁 함께 쓰기<br/>5.1.5 목과 스텁은 명령과 조회에 어떻게 관련돼 있는가 <br/>5.2 식별할 수 있는 동작과 구현 세부 사항 <br/>5.2.1 식별할 수 있는 동작은 공개 API와 다르다 <br/>5.2.2 구현 세부 사항 유출: 연산의 예<br/>5.2.3 잘 설계된 API와 캡슐화<br/>5.2.4 구현 세부 사항 유출: 상태의 예<br/>5.3 목과 테스트 취약성 간의 관계 <br/>5.3.1 육각형 아키텍처 정의<br/>5.3.2 시스템 내부 통신과 시스템 간 통신<br/>5.3.3 시스템 내부 통신과 시스템 간 통신의 예<br/>5.4 단위 테스트의 고전파와 런던파 재고 <br/>5.4.1 모든 프로세스 외부 의존성을 목으로 해야 하는 것은 아니다<br/>5.4.2 목을 사용한 동작 검증<br/>요약 <br/><br/>6장. 단위 테스트 스타일<br/><br/>6.1 단위 테스트의 세 가지 스타일 <br/>6.1.1 출력 기반 테스트 정의<br/>6.1.2 상태 기반 스타일 정의<br/>6.1.3 통신 기반 스타일 정의<br/>6.2 단위 테스트 스타일 비교 <br/>6.2.1 회귀 방지와 피드백 속도 지표로 스타일 비교하기 <br/>6.2.2 리팩터링 내성 지표로 스타일 비교하기<br/>6.2.3 유지 보수성 지표로 스타일 비교하기<br/>6.2.4 스타일 비교하기: 결론<br/>6.3 함수형 아키텍처 이해 <br/>6.3.1 함수형 프로그래밍이란?<br/>6.3.2 함수형 아키텍처란?<br/>6.3.3 함수형 아키텍처와 육각형 아키텍처 비교<br/>6.4 함수형 아키텍처와 출력 기반 테스트로 전환 <br/>6.4.1 감사 시스템 소개<br/>6.4.2 테스트를 파일 시스템에서 분리하기 위한 목 사용 <br/>6.4.3 함수형 아키텍처로 리팩터링하기<br/>6.4.4 예상되는 추가 개발<br/>6.5 함수형 아키텍처의 단점 이해하기 <br/>6.5.1 함수형 아키텍처 적용 가능성<br/>6.5.2 성능 단점<br/>6.5.3 코드베이스 크기 증가<br/>요약 <br/><br/>7장. 가치 있는 단위 테스트를 위한 리팩터링 <br/><br/>7.1 리팩터링할 코드 식별하기 <br/>7.1.1 코드의 네 가지 유형<br/>7.1.2 험블 객체 패턴을 사용해 지나치게 복잡한 코드 분할하기<br/>7.2 가치 있는 단위 테스트를 위한 리팩터링하기 <br/>7.2.1 고객 관리 시스템 소개<br/>7.2.2 1단계: 암시적 의존성을 명시적으로 만들기<br/>7.2.3 2단계: 애플리케이션 서비스 계층 도입<br/>7.2.4 3단계: 애플리케이션 서비스 복잡도 낮추기<br/>7.2..5 4단계: 새 Company 클래스 소개<br/>7.3 최적의 단위 테스트 커버리지 분석 <br/>7.3.1 도메인 계층과 유틸리티 코드 테스트하기<br/>7.3.2 나머지 세 사분면에 대한 코드 테스트하기<br/>7.3.3 전제 조건을 테스트해야 하는가?<br/>7.4 컨트롤러에서 조건부 로직 처리 <br/>7.4.1 CanExecute / Execute 패턴 사용<br/>7.4.2 도메인 이벤트를 사용해 도메인 모델 변경 사항 추적<br/>7.5 결론 <br/>요약 <br/><br/><b>3부. 통합 테스트 </b><br/><br/>8장. 통합 테스트를 하는 이유<br/><br/>8.1 통합 테스트는 무엇인가? <br/>8.1.1 통합 테스트의 역할<br/>8.1.2 다시 보는 테스트 피라미드<br/>8.1.3 통합 테스트와 빠른 실패<br/>8.2 어떤 프로세스 외부 의존성을 직접 테스트해야 하는가 <br/>8.2.1 프로세스 외부 의존성의 두 가지 유형<br/>8.2.2 관리 의존성이면서 비관리 의존성인 프로세스 외부 의존성 다루기<br/>8.2.3 통합 테스트에서 실제 데이터베이스를 사용할 수 없으면 어떻게 할까?<br/>8.3 통합 테스트: 예제 <br/>8.3.1 어떤 시나리오를 테스트할까?<br/>8.3.2 데이터베이스와 메시지 버스 분류하기 <br/>8.3.3 엔드 투 엔드 테스트는 어떤가?<br/>8.3.4 통합 테스트: 첫 번째 시도<br/>8.4 의존성 추상화를 위한 인터페이스 사용 <br/>8.4.1 인터페이스와 느슨한 결합<br/>8.4.2 프로세스 외부 의존성에 인터페이스를 사용하는 이유는 무엇인가?<br/>8.4.3 프로세스 내부 의존성을 위한 인터페이스 사용<br/>8.5 통합 테스트 모범 사례 <br/>8.5.1 도메인 모델 경계 명시하기<br/>8.5.2 계층 수 줄이기<br/>8.5.3 순환 의존성 제거하기<br/>8.5.4 테스트에서 다중 실행 구절 사용<br/>8.6 로깅 기능을 테스트하는 방법 <br/>8.6.1 로깅을 테스트해야 하는가?<br/>8.6.2 로깅을 어떻게 테스트해야 하는가?<br/>8.6.3 로깅이 얼마나 많으면 충분한가?<br/>8.6.4 로거 인스턴스를 어떻게 전달하는가?<br/>8.7 결론 <br/>요약 <br/><br/>9장. 목 처리에 대한 모범 사례<br/><br/>9.1 목의 가치를 극대화하기 <br/>9.1.1 시스템 끝에서 상호 작용 검증하기<br/>9.1.2 목을 스파이로 대체하기<br/>9.1.3 IDomainLogger는 어떤가?<br/>9.2 목 처리에 대한 모범 사례 <br/>9.2.1 목은 통합 테스트만을 위한 것<br/>9.2.2 테스트당 목이 하나일 필요는 없음<br/>9.2.3 호출 횟수 검증하기<br/>9.2.4 보유 타입만 목으로 처리하기<br/>요약 <br/><br/>10장. 데이터베이스 테스트<br/><br/>10.1 데이터베이스 테스트를 위한 전제 조건 <br/>10.1.1 데이터베이스를 형상 관리 시스템에 유지<br/>10.1.2 참조 데이터도 데이터베이스 스키마다 <br/>10.1.3 모든 개발자를 위한 별도의 데이터베이스 인스턴스<br/>10.1.4 상태 기반 데이터베이스 배포와 마이그레이션 기반 데이터베이스 배포<br/>10.2 데이터베이스 트랜잭션 관리 <br/>10.2.1 제품 코드에서 데이터베이스 트랜잭션 관리하기<br/>10.2.2 통합 테스트에서 데이터베이스 트랜잭션 관리하기<br/>10.3 테스트 데이터 생명 주기 <br/>10.3.1 병렬 테스트 실행과 순차적 테스트 실행<br/>10.3.2 테스트 실행 간 데이터 정리<br/>10.3.3 인메모리 데이터베이스 피하기<br/>10.4 테스트 구절에서 코드 재사용하기 <br/>10.4.1 준비 구절에서 코드 재사용하기<br/>10.4.2 실행 구절에서 코드 재사용하기<br/>10.4.3 검증 구절에서 코드 재사용하기<br/>10.4.4 테스트가 데이터베이스 트랜잭션을 너무 많이 생성하는가?<br/>10.5 데이터베이스 테스트에 대한 일반적인 질문 <br/>10.5.1 읽기 테스트를 해야 하는가?<br/>10.5.2 리포지터리 테스트를 해야 하는가?<br/>10.6 결론 <br/>요약 <br/><br/><b>4부. 단위 테스트 안티 패턴</b><br/><br/>11장. 단위 테스트 안티 패턴<br/><br/>11.1 비공개 메서드 단위 테스트 <br/>11.1.1 비공개 메서드와 테스트 취약성<br/>11.1.2 비공개 메서드와 불필요한 커버리지<br/>11.1.3 비공개 메서드 테스트가 타당한 경우<br/>11.2 비공개 상태 노출 <br/>11.3 테스트로 유출된 도메인 지식 <br/>11.4 코드 오염 <br/>11.5 구체 클래스를 목으로 처리하기 <br/>11.6 시간 처리하기 <br/>11.6.1 앰비언트 컨텍스트로서의 시간<br/>11.6.2 명시적 의존성으로서의 시간<br/>11.7 결론 <br/>요약

이 책에서 다루는 내용

- 단위 테스트를 평가하기 위한 범용 지침
- 안티 패턴을 식별하고 피하기 위한 테스트 기법
- 제품 코드와 테스트 코드를 위한 리팩터링 기법
- 전체 시스템을 검증하기 위한 통합 테스트 사용법

이 책의 목표와 대상 독자

대부분의 온라인 자료나 인쇄물에는 한 가지 단점이 있다. 단위 테스트의 기본에 중점을 두지만 그 이상은 다루지 않는다. 이러한 자료에도 많은 가치가 있지만, 거기서 학습이 끝나지는 않는다. 테스트 작성뿐만 아니라 노력 대비 최상의 결과를 얻을 수 있는 방법을 사용하는 다음 단계가 있다. 이 책은 다음 단계로 갈 수 있게 해주며, 이상적인 단위 테스트에 대한 과학적이고 정확한 정의를 제공한다. 이 정의는 보편적인 기준들을 제공해 많은 테스트를 새로운 관점에서 보게 만들고, 그중 어느 것이 프로젝트에 도움되고 어느 것을 리팩터링하거나 제거해야 하는지 알려준다.

단위 테스트 경험이 많다면 이 책에서 많은 것을 배울 수 있다. 숙련된 프로그래머라면 이 책에서 소개한 아이디어 중 몇몇을 이미 이해하고 있을 수도 있다. 이 책은 단위 테스트를 하고자 하는 모든 사람이 사용해온 기술과 모범 사례가 왜 그렇게 유용한지 이해하고 설명하는 데 도움이 된다. 이 기술을 과소 평가하지 말라. 아이디어를 동료에게 명확히 전달하는 능력은 돈을 주고도 살 수 없다.

이 책의 구성

이 책의 11개 장은 크게 네 개 부로 나뉜다. 1부에서는 단위 테스트를 소개하고 일반적인 단위 테스트 원칙을 살펴본다. 1장에서는 단위 테스트의 목표를 정의하고 좋은 테스트와 좋지 않은 테스트를 구별하는 방법을 개략적으로 살펴본다. 2장에서는 단위 테스트의 정의와 단위 테스트의 두 분파를 설명한다. 3장에서는 단위 테스트 구성, 테스트 픽스처(test fixture) 재사용, 테스트 매개변수화와 같은 몇 가지 기본 주제를 되짚어본다.

2부에서는 주제의 핵심을 다룬다. 좋은 단위 테스트를 만드는 방법을 알아보고 테스트를 좀 더 가치 있게 리팩터링하는 방법을 자세히 살펴본다. 4장에서는 좋은 단위 테스트를 구성하고 이 책 전체에서 사용되는 공통적인 기준들이 되는 4대 요소를 정의한다. 5장에서는 목(mock)에 대한 사례를 구축하고 테스트 취약성과의 관계를 알아본다. 6장에서는 단위 테스트의 세 가지 스타일을 살펴보고, 그중 가장 품질이 좋은 스타일은 어느 것이고 그 이유는 무엇인지 알아본다. 7장에서는 테스트를 너무 복잡해지지 않게 리팩터링하고 최소한의 유지비로 최대한의 가치를 얻는 방법을 설명한다.

3부에서는 통합 테스트와 관련된 내용을 다룬다. 8장에서는 통합 테스트가 무엇인지 알아보고, 그 장점과 절충에 대해 전반적으로 살펴본다. 9장에서는 목에 대해 알아보고, 목이 어떻게 테스트에 큰 도움이 되는지를 설명한다. 10장에서는 테스트에서 관계형 데이터베이스와 어떻게 작업하는지를 설명한다 4부의 11장에서는 일반적인 단위 테스트 안티 패턴을 살펴본다. 아마도 그중 몇몇은 전에 만난 적이 있을 수도 있다.

지은이의 말

단위 테스트를 시도했던 첫 번째 프로젝트가 생각난다. 비교적 잘 진행된 프로젝트였지만, 종료된 후 테스트들을 살펴보고 나서 많은 시간 낭비를 했다고 생각했다. 대부분의 단위 테스트는 기대치를 설정하고 거미줄처럼 복잡한 의존성을 연결하는 데 많은 시간이 든다. 단지 컨트롤러에 있는 코드 세 줄이 올바른지 확인하는 것이었다. 테스트에서 정확히 무엇이 잘못됐는지는 바로 알 수는 없었지만, 내 균형 감각이 무언가 잘못됐다는 신호를 보냈다.

다행히도 단위 테스트를 포기하지 않고 이후 프로젝트에 계속 적용했다. 그러나 그 이후로 일반적인 (그 당시) 단위 테스트 관행을 둘러싼 의견 차이가 점점 커지고 있었다. 나는 몇 년 동안 단위 테스트에 관해 많은 글을 썼다. 그 글을 쓰면서 용케 첫 번째 테스트에서 정확히 무엇이 잘못됐는지를 결정할 수 있었고, 이 지식을 단위 테스트의 더 넓은 영역으로 일반화했다. 마침내 이 책으로 그 기간 동안의 모든 연구와 시행착오, 그리고 오류에 대해 (컴파일하고 정제하고 요약해서) 정점에 다다를 수 있었다.

프로그래밍 지침은 수학 이론과 같이 기본 원칙에서 파생돼야 한다고 생각해, 이 책을 그와 비슷한 방식으로 구성하려고 노력했다. 결론으로 바로 도달하거나 근거 없는 주장을 던지지 않고 백지상태로 시작해서, 바닥부터 점진적으로 주장을 세워나간다. 흥미롭게도, 이러한 기본 원칙을 세우면 가이드라인과 모범 사례는 종종 자연스럽게 별 영향이 없어진다.

단위 테스트는 사실상 소프트웨어 프로젝트의 필수 요소이다. 이 책은 단위 테스트의 모범 사례와 일반적인 안티 패턴에 대한 인사이트를 제공한다. 모두 읽고 나면 새로운 기술로 무장해서 유지 보수와 확장이 쉽게 프로젝트를 성공시키는 전문가가 되는 데 필요한 지식을 얻게 될 것이다.

옮긴이의 말

다년간 여러 회사의 크고 작은 프로젝트를 참여하면서 만났던 개발자 중 대다수는 테스트 코드를 작성하는 것을 귀찮아 하고 싫어했었다. 나조차 바쁜 일정에 쫓겨 테스트는 우선순위에 있어 항상 뒤로 미루기 일쑤였다. 프로젝트 초기에 의욕적으로 작성하다가도 프로젝트 막바지에 달했을 때 기존에 있던 테스트 코드를 삭제하는 동료도 종종 봤다. 테스트를 작성하지 않고 이후에 운영 환경에서 커다란 장애를 맞거나 데이터 정합성이 깨져 데이터 복구하는데 고군분투했던 경험이 개발자라면 한 번씩 있었을 것이다.

이 책을 통해 저자는 독자의 입장에서 실무적인 환경에 입각해 독자의 공감을 얻고 이해하는데 도움이 되도록 공을 들였다. 수많은 테스트 관련 책들이 테스트의 본질에 접근했다면, 이 책은 맹목적인 테스트 노력에서 벗어나 실용적인 테스트 구성에 대한 방법론으로 접근한다. 클린 아키텍처 등 자칫 이론으로만 치부할 수 있는 내용을 실무에서 접했을 만한 예제로 어떻게 구성할 수 있는지, 그리고 이 합리적인 구성이 어떻게 테스트를 효과적으로 작성하고 유지할 수 있는지를 하나씩 톺아볼 수 있다. 또한 저자가 생각하는 바를 수학적 접근으로 증명하려는 과정에서 저자의 노력이 돋보인다. 이 책을 읽고 이론에 머물지 않고 실천함으로써, 공학적인 사고로 합리적인 테스트를 작성해서, 독자들이 만드는 소프트웨어의 품질과 생산성이 좋아지고, 더 나아가 소프트웨어 산업의 수준을 한 층 더 높일 수 있기를 기대한다.

"없어서는 안 될 자료다."
- 그렉 라이트 (Greg Wright, 카이노스 소프트웨어(Kainos Software Ltd.))

"아무리 경험이 많다고 하더라도 집중해서 테스트를 잘하려면 격려의 역할을 하는 무언가가 필요하다."
- 마크 네나도프 (Mark Nenadov, 보더커넥트(BorderConnect))

"20년 전 소프트웨어 개발 경력을 시작했을 때 이 책이 있었으면 좋았을 텐데."
- 코너 레드몬드 (Conor Redmond, 인컴 프로덕트 컨트롤(Incomm Product Control))

"오랫동안 기다려온 단위 테스트에 관한 책이다."
- 제레미 랭 (Jeremy Lange, G2)