목차

• 제 1 부 단위 테스트의 기초
• 1장 첫 번째 JUnit 테스트 만들기
• 1.1 단위 테스트를 작성하는 이유
• 1.2 JUnit의 기본: 첫 번째 테스트 통과
• 1.2.1 프로젝트 설정
• 1.2.2 JUnit 테스트 좀 더 이해
• 1.2.3 JUnit 실행
• 1.3 테스트 준비, 실행, 단언
• 1.4 테스트가 정말로 뭔가를 테스트하는가?
• 1.5 마치며
• 2장 JUnit 진짜로써 보기
• 2.1 테스트 대상 이해: Profile 클래스
• 2.2 어떤 테스트를 작성할 수 있는지 결정
• 2.3 단일 경로 커버
• 2.4 두 번째 테스트 만들기
• 2.5 @Before 메서드로 테스트 초기화
• 2.6 이제 어떤가?
• 2.7 마치며
• 3장 JUnit 단언 깊게 파기
• 3.1 JUnit 단언
• 3.1.1 assertTrue
• 3.1.2 assertThat은 명확한 값을 비교
• 3.1.3 중요한 햄크레스트 매처 살펴보기
• 3.1.4 부동소수점 수를 두 개 비교
• 3.1.5 단언 설명
• 3.2 예외를 기대하는 세 가지 방법
• 3.2.1 단순한 방식: 애너테이션 사용
• 3.2.2 옛 방식: try/catch와 fail
• 3.2.3 새로운 방식: ExpectedException 규칙
• 3.2.4 예외 무시
• 3.3 마치며
• 4장 테스트 조직
• 4.1 AAA로 테스트 일관성 유지
• 4.2 동작 테스트 vs 메서드 테스트
• 4.3 테스트와 프로덕션 코드의 관계
• 4.3.1 테스트와 프로덕션 코드 분리
• 4.3.2 내부 데이터 노출 vs 내부 동작 노출
• 4.4 집중적인 단일 목적 테스트의 가치
• 4.5 문서로서의 테스트
• 4.5.1 일관성 있는 이름으로 테스트 문서화
• 4.5.2 테스트를 의미 있게 만들기
• 4.6 @Before와 @After (공통 초기화와 정리) 더 알기
• 4.6.1 BeforeClass와 AfterClass 애너테이션
• 4.7 녹색이 좋다: 테스트를 의미 있게 유지
• 4.7.1 테스트를 빠르게
• 4.7.2 테스트 제외
• 4.8 마치며
• 제 2 부 빠른 암기법 습득
• 5장 좋은 테스트의 FIRST 속성
• 5.1 FIRST: 좋은 테스트 조건
• 5.2 [F]IRST: 빠르다
• 5.3 F[I]RST: 고립시킨다
• 5.4 FI[R]ST: 좋은 테스트는 반복 가능해야 한다
• 5.5 FIR[S]T: 스스로 검증 가능하다
• 5.6 FIRS[T]: 적시에 사용한다
• 5.7 마치며
• 6장 Right-BICEP: 무엇을 테스트할 것인가?
• 6.1 [Right]-BICEP: 결과가 올바른가?
• 6.2 Right-[B]ICEP: 경계 조건은 맞는가?
• 6.3 경계 조건에서는 CORRECT를 기억하라
• 6.4 Right-B[I]CEP: 역 관계를 검사할 수 있는가?
• 6.5 Right-BI[C]EP: 다른 수단을 활용하여 교차 검사할 수 있는가?
• 6.6 Right-BIC[E]P: 오류 조건을 강제로 일어나게 할 수 있는가?
• 6.7 Right-BICE[P]: 성능 조건은 기준에 부합하는가?
• 6.8 마치며
• 7장 경계 조건: CORRECT 기억법
• 7.1 [C]ORRECT:[C]onformance(준수)
• 7.2 C[O]RRECT:[O]rdering(순서)
• 7.3 CO[R]RECT: [R]ange(범위)
• 7.3.1 불변성을 검사하는 사용자 정의 매처 생성
• 7.3.2 불변 메서드를 내장하여 범위 테스트
• 7.4 COR[R]ECT:[R]eference(참조)
• 7.5 CORR[E]CT:[E]xistence(존재)
• 7.6 CORRE[C]T:[C]ardinality(기수)
• 7.7 CORREC[T]: [T]ime(시간)
• 7.8 마치며
• 제 3 부 더 큰 설계 그림
• 8장 깔끔한 코드로리팩토링하기
• 8.1 작은 리팩토링
• 8.1.1 리팩토링의 기회
• 8.1.2 메서드 추출: 두 번째로 중요한 리팩토링 친구
• 8.2 메서드를 위한 더 좋은 집 찾기
• 8.3 자동 및 수동 리팩토링
• 8.4 과한 리팩토링?
• 8.4.1 보상: 명확하고 테스트 가능한 단위들
• 8.4.2 성능 염려: 그러지 않아도 된다
• 8.5 마치며
• 9장 더 큰 설계 문제
• 9.1 Profile 클래스와 SRP
• 9.2 새로운 클래스 추출
• 9.3 명령-질의 분리
• 9.4 단위 테스트의 유지 보수 비용
• 9.4.1 자신을 보호하는 방법
• 9.4.2 깨진 테스트 고치기
• 9.5 다른 설계에 관한 생각들
• 9.6 마치며
• 10장 목 객체 사용
• 10.1 테스트 도전 과제
• 10.2 번거로운 동작을 스텁으로 대체
• 10.3 테스트를 지원하기 위한 설계 변경
• 10.4 스텁에 지능 더하기:인자 검증
• 10.5 목 도구를 사용하여 테스트 단순화
• 10.6 마지막 하나의 단순화: 주입 도구 소개
• 10.7 목을 올바르게 사용할 때 중요한 것
• 10.8 마치며
• 11장 테스트리팩토링
• 11.1 이해 검색
• 11.2 테스트 냄새: 불필요한테스트 코드
• 11.3 테스트 냄새: 추상화 누락
• 11.4 테스트 냄새: 부적절한 정보
• 11.5 테스트 냄새: 부푼 생성
• 11.6 테스트 냄새: 다수의 단언
• 11.7 테스트 냄새: 테스트와무관한 세부 사항들
• 11.8 테스트 냄새: 잘못된 조직
• 11.9 테스트 냄새: 암시적 의미
• 11.10 새로운 테스트 추가
• 11.11 마치며
• 제 4 부 더 큰 단위 테스트 그림
• 12장 테스트 주도 개발
• 12.1 TDD의 주된 이익
• 12.2 단순하게 시작
• 12.3 또 다른 증분 추가
• 12.4 테스트 정리
• 12.5 또 다른 작은 증분
• 12.6 다수의 응답 지원: 작은 설계 우회로
• 12.7 인터페이스 확장
• 12.8 마지막 테스트들
• 12.9 문서로서의 테스트
• 12.10 TDD의 리듬
• 12.11 마치며
• 13장 까다로운 테스트
• 13.1 멀티스레드 코드 테스트
• 13.1.1 단순하고 똑똑하게 유지
• 13.1.2 모든 매칭 찾기
• 13.1.3 애플리케이션 로직 추출
• 13.1.4 스레드 로직의 테스트 지원을 위해 재설계
• 13.1.5 스레드 로직을 위한 테스트 작성
• 13.2 데이터베이스 테스트
• 13.2.1 고마워, Controller
• 13.2.2 데이터 문제
• 13.2.3 클린 룸 데이터베이스 테스트
• 13.2.4 controller를 목 처리
• 13.3 마치며
• 14장 프로젝트에서 테스트
• 14.1 빠른 도입
• 14.2 팀과 같은 편 되기
• 14.2.1 단위 테스트 표준 만들기
• 14.2.2 리뷰로 표준 준수 높이기
• 14.2.3 짝 프로그래밍을 이용한 리뷰
• 14.3 지속적 통합으로 수렴
• 14.4 코드 커버리지
• 14.4.1 커버리지는 어느 정도여야 하는가?
• 14.4.2 100% 커버리지는 진짜 좋은가?
• 14.4.3 코드 커버리지의 가치
• 14.5 마치며
• 부록 A 인텔리제이 IDEA와 넷빈즈에서 JUnit 설정
• A.1 인텔리제이 IDEA
• A.2 넷빈즈2