『xUnit 테스트 패턴』은 가장 인기 있는 단위 테스트 프레임워크인 xUnit으로 자동 테스트를 작성하는 방법을 완벽하게 지도해준다. 애자일 코치이자 테스트 자동화 전문가인 제라드 메스자로스(Gerard Meszaros)는 테스트 작성, 이해, 유지 보수를 쉽게 해주는 68개의 입증된 패턴을 소개한다. 또한 어떻게 하면 테스트를 더 견고하고 반복 가능하며, 쉽게 만들 수 있는지도 보여준다.


[ 소개 ]

자동 테스팅(Automated testing)은 애자일 개발의 기초다. 테스팅 전략을 잘 활용하면 기능을 과감하게 추가할 수 있고, 사용자 피드백을 빠르게 받을 수 있으며, 품질을 향상시킬 수 있다. 하지만 대다수 개발자가 자동 테스트에 대한 경험이 부족해 효과적인 테스트 작성을 어려워한다.

『xUnit 테스트 패턴』은 가장 인기 있는 단위 테스트 프레임워크인 xUnit으로 자동 테스트를 작성하는 방법을 완벽하게 지도해준다. 애자일 코치이자 테스트 자동화 전문가인 제라드 메스자로스(Gerard Meszaros)는 테스트 작성, 이해, 유지 보수를 쉽게 해주는 68개의 입증된 패턴을 소개한다. 또한 어떻게 하면 테스트를 더 견고하고, 반복 가능하며, 쉽게 만들 수 있는지도 보여준다.

도표, 패턴 목록 PDF 보기>>


[ 이 책에서 다루는 내용 ]

■ 테스트를 더 빠르게, 잘 작성하는 방법
■ 자동 테스트의 4단계: 픽스처 설치, 테스트 대상 시스템 실행, 결과 검증, 픽스처 해체
■ 테스트 스텁(Test Stub)과 모의 객체(Mock Object)로 소프트웨어를 환경으로부터 격리시켜 테스트 커버리지를 향상시키는 방법
■ 테스트하기 좋게 소프트웨어를 설계하는 방법
■ (코드 냄새, 동작 냄새, 프로젝트 냄새 등) 테스트 ‘냄새’로 문제를 파악하고, 이런 냄새를 언제 어떻게 제거할 수 있는지 알아내는 방법
■ 테스트를 리팩토링해 더 단순하고 견고하며 빠르게 실행될 수 있게 만드는 방법


[ 이 책의 대상 독자 ]

개발자, 관리자, 테스터에게 필요한 책이다. 애자일 개발 환경에서 일하느냐, 전통적인 개발 환경에서 일하느냐, 테스트 주도 개발을 하느냐, 테스트를 나중에 작성하느냐는 중요하지 않다. 이 책에서 나온 패턴과 냄새들은 모든 xUnit 계열에 적용할 수 있을 뿐만 아니라 차세대 동작 주도 개발(Behavior-Driven Development) 프레임워크인 RSpect, JBehave뿐만 아니라 기록 테스트 툴이라든지, Fit나 FitNesse 같은 데이터 주도 테스트(Data-Driven Test) 툴에서도 활용할 수 있다.


[ 이 책의 구성 ]

이 책은 3권의 책을 한 권으로 합쳐 놓은 듯한 방대한 내용으로 구성돼있다.

1부에서는 테스트 전략에서부터 실제 테스트 코딩까지 테스트 자동화에 대한 모든 것을 자세하게 설명한다.

2부에서는 자주 만날 수 있는 18가지 ‘테스트 냄새’ 목록을 보여주고, 문제의 근본 원인과 그에 맞는 가장 적당한 패턴을 찾는 데 도움을 주는 해결 방안을 제공한다.

3부에서는 각 패턴을 자세하게 설명하고, 다양한 프로그래밍 언어로 작성된 예제 코드를 통해 리팩토링하는 방법을 보여준다.


[ 추천의 글 ]

junit.org에 가보면 제가 다음과 같이 써 놓은 글을 볼 수 있습니다. “소프트웨어 개발에 있어 이처럼 많은 사람이 이렇게 적은 코드로부터 이런 큰 도움을 받은 적은 없었다.” 많은 사람이 JUnit을 똑똑한 프로그래머가 일주일이면 만들 수 있는 별 거 아닌 것이라고 혹평해왔습니다. 그런 평가가 사실일지는 몰라도 핵심에는 완전히 벗어나 있습니다. JUnit이 중요하고 처칠의 연설(“인류 분쟁의 영역에 있어 이처럼 많은 사람이 이렇게 적은 사람들에게 이런 큰 도움을 받은 적이 없었다.”라는 연설은 처칠이 영국 본토항공전 승리 이후 왕립공군 조종사들의 노고를 치하하며 한 말임 - 옮긴이)을 패러디할 자격이 있는 이유는, 이런 작은 도구 덕분에 수많은 프로그래머에게 테스팅이 프로그래밍의 중심이자 전면으로 떠오를 수 있는 계기가 됐기 때문입니다. 이전에도 이를 주장해 온 사람들이 있었지만 무엇보다도 JUnit이 이런 변화에 가장 크게 기여했습니다.

물론 xUnit은 단순한 JUnit이 아닌 그 이상의 것입니다. JUnit은 수많은 프로그래밍 언어로 포팅됐습니다. xUnit 도구라고 불리기도 하는 일가친척 같은 도구들은 자바라는 뿌리를 넘어 멀리멀리 퍼져나갔습니다(사실 뿌리는 자바가 아닙니다. JUnit보다 몇 년 전에 켄트 벡(Kent Beck)이 스몰토크로 먼저 만들었습니다).

xUnit 툴과 철학은 프로그래밍 팀이 적은 리스크로 코드를 대단위로 수정할 수 있게 도와주는 강력한 회귀 테스트 스위트를 작성할 수 있고, 테스트 주도 개발로 설계 과정을 다시 생각해볼 수 있는 굉장한 기회를 제공합니다.

하지만 이런 기회와 더불어 새로운 문제와 기술도 생겼습니다. 다른 도구처럼 xUnit은 능숙하게 쓰이는 경우도 있지만 서투르게 쓰이기도 합니다. 똑똑한 사람들은 xUnit으로 테스트와 데이터를 효과적으로 조직할 수 있는 여러 방법을 찾아냈습니다. 초창기 객체지향 시대에서처럼 xUnit 도구를 잘 사용할 수 있는 지식 대부분은 숙련된 사람들의 머릿속에만 숨어 있습니다. 이렇게 숨어있는 지식 없이는 xUnit의 혜택을 100% 얻지 못합니다.

객체지향 쪽 사람들이 객체에 이런 문제가 있다는 걸 깨닫고 해답을 찾기 시작한 것이 거의 20년 전입니다. 그 해답은 숨어있는 지식을 패턴 형식으로 작성하는 것이었습니다. 제라드 메스자로스(Gerard Meszaros)는 이런 일을 하는 선구자 중 한 명이었습니다. 제가 처음 패턴을 공부할 때 제라드는 제가 배웠던 리더 중 한 명이었습니다. 패턴 세계에 있는 다른 여러 사람처럼 제라드 역시 익스트림 프로그래밍을 초창기에 도입했고 덕분에 초창기부터 xUnit 도구로 작업해왔습니다. 이러니 제라드가 이런 전문 지식을 패턴 형식으로 기록하는 작업을 맡는 건 당연합니다.

저는 처음 이 프로젝트에 대한 얘기를 듣고 굉장히 들떴습니다(저는 이 책을 저의 마틴 파울러 시리즈에 추가하고 싶었으므로 온갖 수를 다 써서 이 책을 밥 마틴(Bob Martin) 시리즈에서 빼내왔습니다). 다른 좋은 패턴 책과 마찬가지로 이 책은 새로운 사람들에게 이 쪽 분야에 대한 지식을 제공할 뿐만 아니라 경험 많은 전문가가 자신의 지식을 동료들에게 전달하기 위한 용어와 기초를 제공합니다. 유명한 Gang of Four의 책인 『디자인 패턴(Design Patterns)』이 많은 사람에게 객체지향 설계의 숨어있는 보물상자를 열어주었듯이 이 책 또한 xUnit에 있어 중요한 책이 되리라 믿습니다.

[ 저자 소개 ]

제라드 메스자로스(Gerard Meszaros)
캘거리(Calgary)에 있는 애자일 개발 전문 컨설팅 회사 클리어스트림 컨설팅(ClearStream Consulting)의 수석 과학자(Chief Scientist)이자 선임 컨설턴트다. 제라드는 십 년 이상 자동 단위 테스트 프레임워크 분야에서 경험을 쌓았고 테스트 자동 패턴, 소프트웨어와 테스트 리팩토링, 테스트 용이성을 위한 설계 분야를 선도하는 전문가다.


[ 옮긴이의 말 ]

어느덧 ‘단위 테스트’라는 단어가 개발자들 사이에서 익숙해졌습니다. 팀에 적용하고 있다는 분들도 많더군요. JUnit은 4.8까지 나왔고, 구글에서도 GoogleTest 같은 프로젝트가 나왔습니다. CruiseControl이나 Hudson 같은 CI(Continuous Integration) 툴에 단위 테스트를 붙여 지속적인 통합을 하는 팀뿐만 아니라, 단위 테스트 코드 커버리지 90% 이상 달성을 KPI로 잡는 개발 팀도 있다고 들었습니다.

이렇게 단위 테스트가 많이 전파된 것처럼 보이지만 막상 개발자들 얘기를 들어보면 고민이 많습니다. “제대로 된 책도 별로 없고, 모의 객체(Mock Object)를 어떻게 설정해야 하는지 잘 모르겠고, 함수 하나만 고쳐도 컴파일 에러가 너무 많이 나서 개발에 거치적거리는 것만 같고, 관리자는 그런 거 왜 하냐고 무시하기나 하고, 에이... 그냥 하지 말까...”

리니지2 개발 팀에서는 2007년 4월부터 단위 테스트(UnitTest++)를 도입했습니다. 처음부터 쉬웠던 건 아닙니다. 코드 여기저기를 #ifdef USING_TDD로 감싸줬음에도 불구하고 테스트 대상 시스템(System Unter Test, SUT) 코드를 잘못 건드리는 바람에 오히려 없던 버그를 만들기도 하고, if (g_bTesting) 같은 테스트 훅(Test Hook)을 잘못 넣거나, 공유 픽스처(Shared Fixture)를 제대로 해체(Teardown)하지 않아서 다른 팀원들까지 많이 고생시켰습니다.

하지만 많은 분이 도와주신 덕분에 단위 테스트는 점차 안정되어 갔습니다. 2007년에 200여 개였던 단위 테스트는 2009년에는 1,300개 이상으로 늘었습니다. 단위 테스트가 실패하면 개발 팀 전원에게 이메일을 보내 왜 테스트가 깨졌는지를 모두가 공유하고 도와줄 수 있게 했습니다. 덕분에 나중에는 기획 팀과 함께 단위 테스트 코드를 보면서 기능이 수정될 때 결과가 어떨지를 바로 확인할 수 있었고, 훨씬 편안한 마음으로 리팩토링하고 새로운 기능을 빠르게 추가할 수 있었습니다. KGC(Korea Games Conference) 2008 강연을 준비하면서 단위 테스트가 팀의 개발에 어떤 도움을 주었는지를 보기 위해 버그 트래커 자료를 기반으로 개발 기간 동안 발생한 버그 개수와 에러 수정에 걸리는 시간을 팀 전체와 단위 테스트가 적용된 파트로 나눠 조사해봤습니다. 그 결과 단위 테스트 개수가 늘어날수록 버그 발생 비율이 낮아지고, 버그 수정 속도도 최대 2배 이상 빨라졌음을 알 수 있었습니다(관련 자료: http://parkpd.egloos. com/1944077).

이 책 『xUnit 테스트 패턴』에는 단위 테스트에 대한 거의 모든 정보가 들어 있습니다. “이 책을 1~2년만 더 빨리 읽었더라면 삽질을 덜 했을 텐데”하는 생각에 아쉬움도 들더군요. “우리 프로젝트에서는 어떻게 적용해볼 수 있을까”를 생각하면서 읽으면 더 재미있게 보실 수 있습니다. 이해가 잘 안 될 때는 예제 코드를 먼저 보세요. 때로는 천마디 글보다 한 줄의 코드가 더 이해하기 쉬울 때가 있으니까요.


[ 옮긴이 소개 ]

박일
연세대 컴퓨터과학과를 졸업했다. 2000년 초에 개발을 시작해 지금은 리니지2 서버 팀에서 근무 중이다. 옮긴 책으로는 『스크럼』(2008년)이 있다.

목차

• 1부 설명
  
• 1장 간단하게 둘러보기
  • 개요
  • 가장 확실하면서도 간단한 테스트 자동화 전략
    • 개발 프로세스
    • 고객 테스트
    • 단위 테스트
    • 테스트하기 쉬운 설계
    • 테스트 조직
  • 정리
    
• 2장 테스트 냄새 85
  • 개요
  • 테스트 냄새 소개
    • 테스트 냄새란?
    • 테스트 냄새의 종류
    • 냄새가 날 때 대처 방안
  • 냄새 분류
    • 프로젝트 냄새
    • 동작 냄새
    • 코드 냄새
  • 정리
    
• 3장 테스트 자동화의 목표
  • 개요
  • 테스트를 하는 이유
    • 테스트 자동화 경제학
  • 테스트 자동화의 목표
    • 테스트는 품질 향상에 도움이 돼야 한다
    • 테스트는 SUT를 이해하는 데 도움이 돼야 한다
    • 테스트는 위험을 줄여야(추가하지도 않아야) 한다
    • 테스트는 실행하기 쉬워야 한다
    • 테스트는 만들고 유지하기 쉬워야 한다
    • 테스트는 두 가지 이유로 복잡해진다
    • 시스템이 발전하는 동안 테스트에 필요한 유지 보수 비용이 최소화돼야 한다
  • 정리 108
    
• 4장 테스트 자동화의 철학
  • 개요
  • 철학이 중요한 이유
  • 철학적 차이점
    • 테스트 먼저냐 테스트 나중이냐?
    • 테스트냐 예제냐?
    • 단계별 테스트냐 한꺼번에 테스트냐?
    • 밖에서 안으로냐 안에서 밖으로냐?
    • 동작 검증이냐 상태 검증이냐?
    • 픽스처를 미리 설계하기냐 픽스처를 단계별 테스트에 따라 설계하기냐?
  • 철학이 다를 때
  • 나의 철학
  • 정리
    
• 5장 테스트 자동화의 원칙
  • 개요
  • 원칙
  • 정리
    
• 6장 테스트 자동화 전략
  • 개요
  • 무엇이 전략적인가?
  • 어떤 종류의 테스트를 자동화해야 하는가?
    • 기능별 테스트
    • 교차 기능 테스트
  • 어떤 테스트 자동화에는 어떤 도구를 사용하는가?
    • 테스트 자동화 방식과 방법
    • xUnit 소개
    • xUnit의 스윗 스팟
  • 어떤 테스트 픽스처 전략을 사용하는가?
    • 무엇이 픽스처인가?
    • 주요 픽스처 전략
    • 1회용 신선한 픽스처
    • 지속되는 신선한 픽스처
    • 공유 픽스처 전략
  • 테스트 용이성을 보장하는 방법
    • 테스트 나중 - 각오가 돼 있는가?
    • 테스트하기 쉬운 설계 - 미리 하기
    • 테스트 주도 테스트 용이성
    • 제어 위치와 관찰 위치
    • 상호작용 방식과 테스트 용이성 패턴
    • 나눈 후 테스트
  • 정리
    
• 7장 xUnit 기초
  • 개요
  • xUnit 소개
  • 공통 특징
  • 최소한 알아야 할 것
    • 테스트 정의하기
    • 픽스처란?
    • 테스트들의 스위트 정의
    • 테스트 실행
    • 테스트 결과
  • xUnit의 내부
    • 테스트 명령
    • 테스트 스위트 객체
  • 절차적 세상에서의 xUnt
  • 정리
    
• 8장 1회용 픽스처 관리
  • 개요
  • 테스트 픽스처 용어
    • 픽스처란?
    • 신선한 픽스처란?
    • 무엇이 1회용 신선한 픽스처인가?
  • 신선한 픽스처 생성
    • 인라인 픽스처 설치
    • 위임 픽스처 설치
    • 암묵적 픽스처 설치
    • 혼합형 픽스처 설치
  • 1회용 신선한 픽스처 해체하기
  • 정리
    
• 9장 지속되는 픽스처 관리
  • 개요
  • 지속되는 신선한 픽스처 관리
    • 무엇이 픽스처를 지속하게 만드는가?
    • 지속되는 신선한 픽스처로 인해 생기는 문제
    • 지속되는 신선한 픽스처 해체하기
    • 해체 코드를 아예 필요 없게 만들기
    • 느린 테스트에 대처하기
  • 공유 픽스처 관리
    • 공유 픽스처 접근하기
    • 공유 픽스처 생성자 호출하기
  • 정리
    
• 10장 결과 검증
  • 개요
  • 자체 검사 테스트 만들기
    • 상태 검증이냐 동작 검증이냐?
  • 상태 검증
    • 내장 단언문 사용하기
    • 델타 단언문
    • 외부 결과 검증
  • 동작 검증
    • 절차형 동작 검증
    • 기대 동작 명세
  • 테스트 코드 중복 줄이기
    • 기대 객체
    • 맞춤 단언문
    • 결과를 설명하는 검증 메소드
    • 인자를 받는 테스트와 데이터 주도 테스트
  • 테스트 내 조건문 로직 피하기
    • if문 제거하기
    • 반복문 제거하기
  • 기타 기법
    • 거꾸로, 밖에서 안으로 작업하기
    • 테스트 주도 개발로 테스트 유틸리티 메소드 작성하기
    • 재사용 가능한 검증 로직을 둘 위치
  • 정리
    
• 11장 테스트 대역 사용
  • 개요
  • 간접 입력과 간접 출력
    • 간접 입력을 신경 써야 하는 이유
    • 간접 출력을 신경 써야 하는 이유
    • 간접 입력은 어떻게 제어할 수 있을까?
    • 간접 출력은 어떻게 검증할 것인가?
  • 대역으로 테스트하기
    • 테스트 대역의 종류
    • 테스트 대역 제공하기
    • 테스트 대역 설정하기
    • 테스트 대역 설치하기
  • 테스트 대역의 다른 용도
    • 내시경 테스팅
    • 필요 주도 개발
    • 픽스처 설치 빠르게 하기
    • 테스트 실행 빠르게 하기
  • 기타 고려 사항
  • 정리
    
• 12장 테스트 조직하기
  • 개요
  • 기본 xUnit 메커니즘
  • 적당한 크기의 테스트 메소드
  • 테스트 메소드와 테스트케이스 클래스
    • 클래스별 테스트케이스 클래스
    • 기능별 테스트케이스 클래스
    • 픽스처별 테스트케이스 클래스
    • 테스트 메소드 조직 전략 선택하기
  • 테스트 이름 규약
  • 테스트 스위트 조직하기
    • 테스트 집단 실행하기
    • 하나의 테스트 실행하기
  • 테스트 코드 재사용
    • 테스트 유틸리티 메소드 위치
    • 테스트케이스 상속과 재사용
  • 테스트 파일 구성
    • 내장 자체 테스트
    • 테스트 패키지
    • 테스트 의존
  • 정리
    
• 13장 데이터베이스와 테스트
  • 개요
  • 데이터베이스 테스트하기
    • 데이터베이스를 이용한 테스트가 필요한 이유
    • 데이터베이스와 관련된 문제
  • 데이터베이스 없이 테스트하기
  • 데이터베이스 테스트하기
    • 저장 프로시저 테스트하기
    • 데이터 접근 레이어 테스트하기
    • 개발자의 독립성 보장하기
  • 데이터베이스로 테스트하기(한 번 더!)
  • 정리
    
• 14장 효과적인 테스트 자동화를 위한 길잡이
  • 개요
  • 테스트 자동화의 어려움
  • 자동 테스트를 유지 보수하기 좋게 만드는 길잡이
    • 주요 경로 코드 실행
    • 주요 경로의 직접 출력 값 검증
    • 대안 경로 검증
    • 간접 출력 동작 검증
    • 테스트 실행과 유지 보수 최적화
  • 정리
    
• 2부 테스트 냄새
  
• 15장 코드 냄새
  • 애매한 테스트(Obscure Test)
  • 테스트 내 조건문 로직(Conditional Test Logic)
  • 테스트하기 힘든 코드(Hard-to-Test Code)
  • 테스트 코드 중복(Test Code Duplication)
  • 제품 코드 내 테스트 로직(Test Logic in Production)
    
• 16장 동작 냄새
  • 단언 룰렛(Assertion Roulette)
  • 변덕스러운 테스트(Erratic Test)
  • 깨지기 쉬운 테스트(Fragile Test)
  • 잦은 디버깅(Frequent Debugging)
  • 수동 조정(Manual Intervention)
  • 느린 테스트(Slow Test)
    
• 17장 프로젝트 냄새
  • 버그투성이 테스트(Buggy Test)
  • 테스트를 작성하지 않는 개발자(Developers Not Writing Test)
  • 높은 테스트 유지 비용(High Test Maintenance Cost)
  • 제품 버그(Production Bug)
    
• 3부 패턴
  
• 18장 테스트 전략 패턴
  • 기록 테스트(Recorded Test)
  • 스크립트 기반 테스트(Scripted Test)
  • 데이터 주도 테스트(Data-Driven Test)
  • 테스트 자동 프레임워크(Test Automation Framework)
  • 최소 픽스처(Minimal Fixture)
  • 표준 픽스처(Standard Fixture)
  • 신선한 픽스처(Fresh Fixture)
  • 공유 픽스처(Shared Fixture)
  • 뒷문 조작(Back Door Manipulation)
  • 레이어 테스트(Layer Test)
    
• 19장 xUnit 기본 패턴
  • 테스트 메소드(Test Method)
  • 4단계 테스트(Four-Phase Test)
  • 단언 메소드(Assertion Method)
  • 단언 메시지(Assertion Message)
  • 테스트케이스 클래스(Testcase Class)
  • 테스트 실행기(Test Runner)
  • 테스트케이스 객체(Testcase Object)
  • 테스트 스위트 객체(Test Suite Object)
  • 테스트 찾기(Test Discovery)
  • 테스트 나열(Test Enumeration)
  • 테스트 선택(Test Selection)
    
• 20장 픽스처 설치 패턴
  • 인라인 설치(In-line Setup)
  • 위임 설치(Delegated Setup)
  • 생성 메소드(Creation Method)
  • 암묵적 설치(Implicit Setup)
  • 미리 만든 픽스처(Prebuilt Fixture)
  • 지연 설치(Lazy Setup)
  • 스위트 픽스처 설치(Suite Fixture Setup)
  • 설치 데코레이터(Setup Decorator)
  • 엮인 테스트(Chained Test)
    
• 21장 결과 검증 패턴
  • 상태 검증(State Verification)
  • 동작 검증(Behavior Verification)
  • 맞춤 단언문(Custom Assertion)
  • 델타 단언문vDelta Assertion)
  • 보호 단언문(Guard Assertion)
  • 작업 중인 테스트 단언문(Unfinished Test Assertion)
    
• 22장 픽스처 해체 패턴
  • 가비지 컬렉션 해체(Garbage-Collected Teardown)
  • 자동 해체(Automated Teardown)
  • 인라인 해체(In-line Teardown)
  • 암묵적 해체(Implicit Teardown)
    
• 23장 테스트 대역 패턴
  • 테스트 대역(Test Double)
  • 테스트 스텁(Test Stub)
  • 테스트 스파이(Test Spy)
  • 모의 객체(Mock Object)
  • 가짜 객체(Fake Object)
  • 설정되는 테스트 대역(Configurable Test Double)
  • 하드 코딩된 테스트 대역(Hard-Coded Test Double)
  • 테스트용 하위클래스(Test-Specific Subclass)
    
• 24장 테스트 조직 패턴
  • 이름 있는 테스트 스위트(Named Test Suite)
  • 테스트 유틸리티 메소드(Test Utility Method)
  • 인자를 받는 테스트(Parameterized Test)
  • 클래스별 테스트케이스 클래스(Testcase Class per Class)
  • 기능별 테스트케이스 클래스(Testcase Class per Feature)
  • 픽스처별 테스트케이스 클래스(Testcase Class per Fixture)
  • 테스트케이스 상위클래스(Testcase Superclass)
  • 테스트 도우미(Test Helper)
    
• 25장 데이터베이스 패턴
  • 데이터베이스 샌드박스(Database Sandbox)
  • 저장 프로시저 테스트(Stored Procedure Test)
  • 테이블 삭제 해체(Table Truncation Teardown)
  • 트랜잭션 롤백 해체(Transaction Rollback Teardown)
    
• 26장 테스트하기 쉬운 패턴
  • 의존 주입(Dependency Injection)
  • 의존 찾기(Dependency Lookup)
  • 대강 만든 객체(Humble Object)
  • 테스트 훅(Test Hook)
    
• 27장 갑 패턴
  • 리터럴 값(Literal Value)
  • 파생 값(Derived Value)
  • 생성 값(Generated Value)
  • 더미 객체(Dummy Object)
    
• 4부 부록
  
• 부록 A 테스트 리팩토링
• 부록 B xUnit 용어 정리
• 부록 C xUnit 계열
• 부록 D 도구
• 부록 E 목표와 원칙
• 부록 F 냄새, 별명, 원인

[ p159-169 장 제목 ]
xUint 기초 → xUnit 기초

[ p480 세 번째 문단 1행 ]
하나의 테스트 메소드(458페이지)에 → 하나의 테스트 메소드(468페이지)에