[POD] TDD에 대한 오해와 진실 TDD 이야기

1장. 반가워, TDD
__1.1 TDD, 어디에 쓰는가?
__1.2 지금 TDD가 필요하다

2장. TDD에 관한 오해와 진실
__2.1 (오해 1) TDD는 비용이 더 들고, 결국 개발 속도를 저하시킨다
__2.2 (오해 2) 코드 커버리지가 높으면 좋은 코드다
__2.3 (오해 3) 진압보다 예방에 소비되는 비용이 높다
__2.4 (진실 1) TDD != Unit Testing
__2.5 (진실 2) TDD는 설계 개선에 도움을 준다

3장. 현장 이야기
__3.1 Mock 객체, 언제 그리고 어떻게 사용할까?
__3.2 Fixture, 어떻게 사용해야 할까?
__3.3 TDD와 디자인 패턴의 아름다운 동행
__3.4 private 메서드 그리고 단위 테스트
__3.5 만지기 싫은 레거시 코드, TDD가 해법이다

4장. TDD, 올바른 사용과 사용 습관
__4.1 Top-Down으로 방향을 잡고, Bottom-Up으로 구현에 집중하자
__4.2 바보 단계 거치기
__4.3 시나리오 구상하기
__4.4 TDD의 단위 테스트를 문서화하자

Appendix 마틴 파울러의 "Mock은 Stub이 아니다."
__Mock과 Stub의 구분을 넘어서
__Driving TDD(TDD 진행 방식의 차이)
__Fixture Setup(Fixture, 얼마나 어떻게 사용하는가?)
__Isolation(단위 테스트 격리에 대한 관점의 차이)
__Coupling Tests to Implementations(단위 테스트와 구현체의 결합도에 따른 영향)
__Design Style(테스트가 설계에 미치는 영향)
__다양한 시각, 점진적 사용, 그리고 성장