PART 1 기반 다지기CHAPTER 1 좋은 테스트의 약속1.1 더 좋은 테스트를 작성하기 위한 현황 점검 1.2 테스트의 가치 1.2.1 생산성에 영향을 주는 요소 1.2.2 설계 잠재력 곡선 1.3 설계 수단으로써의 테스트 1.3.1 테스트 주도 개발 1.3.2 행위 주도 개발 1.4 요약 CHAPTER 2 좋은 테스트란?2.1 읽기 쉬운 코드가 유지보수도 쉽다 2.2 구조화가 잘 되어 있다면 이해하기 쉽다 2.3 엉뚱한 걸 검사하는 건 좋지 않다 2.4 독립적인 테스트는 혼자서도 잘 실행된다 2.5 믿음직한 테스트라야 기댈 수 있다 2.6 모든 일이 그렇듯 테스트에도 도구가 쓰인다 2.7 요약 CHAPTER 3 테스트 더블3.1 테스트 더블의 위력 3.1.1 테스트 대상 코드를 격리한다 3.1.2 테스트 속도를 개선한다 3.1.3 예측 불가능한 실행 요소를 제거한다 3.1.4 특수한 상황을 시뮬레이션한다 3.1.5 감춰진 정보를 얻어낸다 3.2 테스트 더블의 종류 3.2.1 테스트 스텁은 유난히 짧다 3.2.2 가짜 객체는 뒤끝 없이 처리한다 3.2.3 테스트 스파이는 기밀을 훔친다 3.2.4 Mock 객체는 예기치 않은 일을 막아준다 3.3 테스트 더블 활용 지침 3.3.1 용도에 맞는 더블을 선택하라 3.3.2 준비하고, 시작하고, 단언하라 3.3.3 구현이 아니라 동작을 확인하라 3.3.4 자신의 도구를 선택하라3.3.5 종속 객체를 주입하라3.4 요약 PART 2 테스트 냄새CHAPTER 4 가독성4.1 기본 타입 단언 4.2 광역 단언 4.3 비트 단언 4.4 부차적 상세정보 4.5 다중 인격 4.6 쪼개진 논리 4.7 매직 넘버 4.8 셋업 설교 4.9 과잉보호 테스트 4.10 요약 CHAPTER 5 유지보수성 5.1 중복 5.2 조건부 로직 5.3 양치기 테스트 5.4 파손된 파일 경로 5.5 끈질긴 임시 파일 5.6 잠자는 달팽이 5.7 픽셀 퍼펙션 5.8 파라미터화된 혼란 5.9 메서드 간 응집력 결핍 5.10 요약 CHAPTER 6 신뢰성 6.1 주석으로 변한 테스트 6.2 오해를 낳는 주석 6.3 절대 실패하지 않는 테스트 6.4 지키지 못할 약속 6.5 낮아진 기대치 6.6 플랫폼 편견 6.7 조건부 테스트 6.8 요약 CHAPTER 7 테스트 가능 설계 7.1 테스트 가능 설계란? 7.1.1 모듈러 설계 7.1.2 SOLID 설계 원칙 7.1.3 맥락을 고려한 모듈러 설계 7.1.4 모듈러 설계를 위한 시운전 7.2 테스트 불가 원인 7.2.1 클래스 생성 불가 7.2.2 메서드 호출 불가 7.2.3 결과 확인 불가 7.2.4 협력 객체 대체 불가 7.2.5 메서드 오버라이딩 불가 7.3 테스트 가능 설계를 위한 지침 7.3.1 복잡한 private 메서드를 피하라 7.3.2 final 메서드를 피하라 7.3.3 정적 메서드를 피하라 7.3.4 new는 신중하게 사용하라 7.3.5 생성자에서는 로직 구현을 피하라 7.3.6 싱글톤을 피하라 7.3.7 상속보다는 컴포지션을 사용하라 7.3.8 외부 라이브러리를 감싸라 7.3.9 서비스 호출을 피하라 7.4 요약 CHAPTER 8 제2의 JVM 언어를 활용한 테스트 작성 8.1 JVM 언어 혼용의 조건 8.1.1 일반적인 이점 8.1.2 테스트 작성하기 8.2 그루비로 단위 테스트 작성하기 8.2.1 간소화된 테스트 셋업 8.2.2 그루비로 작성한 JUnit 4 테스트 8.3 BDD 도구의 뛰어난 표현력 8.3.1 easyb로 작성한 그루비 명세 8.3.2 테스트의 표현력을 높여주는 스폭 8.3.3 스폭의 또 다른 무기, 테스트 더블 8.4 요약 CHAPTER 9 테스트 속도 개선 9.1 속도 개선을 위해서 9.1.1 더 빠르게! 9.1.2 상황 속으로 9.1.3 빌드 프로파일링하기 9.1.4 테스트 프로파일링하기 9.2 테스트 코드 속도 높이기 9.2.1 피곤하지 않다면 잠들지 말라 9.2.2 덩치 큰 기반 클래스를 경계하라 9.2.3 불필요한 셋업과 티어다운을 경계하라 9.2.4 테스트에 초대할 손님은 까다롭게 선택하라 9.2.5 로컬하게, 그리고 빠르게 유지하라 9.2.6 데이터베이스의 유혹을 뿌리쳐라 9.2.7 파일 I/O보다 느린 I/O는 없다 9.3 빌드 속도 높이기 9.3.1 램 디스크를 활용한 초고속 I/O 9.3.2 빌드 병렬화하기 9.3.3 고성능 CPU에 짐 떠넘기기 9.3.4 빌드 분산하기 9.4 요약 Appendix 부록 Appendix A JUnit 기초 A.1 기본적인 JUnit 테스트 케이스 A.2 JUnit 단언문 Appendix B JUnit 확장하기 B.1 러너를 통해 테스트 동작 제어하기 B.2 규칙으로 테스트 꾸미기 B.3 기본 규칙들
PART 1 기반 다지기CHAPTER 1 좋은 테스트의 약속1.1 더 좋은 테스트를 작성하기 위한 현황 점검 1.2 테스트의 가치 1.2.1 생산성에 영향을 주는 요소 1.2.2 설계 잠재력 곡선 1.3 설계 수단으로써의 테스트 1.3.1 테스트 주도 개발 1.3.2 행위 주도 개발 1.4 요약 CHAPTER 2 좋은 테스트란?2.1 읽기 쉬운 코드가 유지보수도 쉽다 2.2 구조화가 잘 되어 있다면 이해하기 쉽다 2.3 엉뚱한 걸 검사하는 건 좋지 않다 2.4 독립적인 테스트는 혼자서도 잘 실행된다 2.5 믿음직한 테스트라야 기댈 수 있다 2.6 모든 일이 그렇듯 테스트에도 도구가 쓰인다 2.7 요약 CHAPTER 3 테스트 더블3.1 테스트 더블의 위력 3.1.1 테스트 대상 코드를 격리한다 3.1.2 테스트 속도를 개선한다 3.1.3 예측 불가능한 실행 요소를 제거한다 3.1.4 특수한 상황을 시뮬레이션한다 3.1.5 감춰진 정보를 얻어낸다 3.2 테스트 더블의 종류 3.2.1 테스트 스텁은 유난히 짧다 3.2.2 가짜 객체는 뒤끝 없이 처리한다 3.2.3 테스트 스파이는 기밀을 훔친다 3.2.4 Mock 객체는 예기치 않은 일을 막아준다 3.3 테스트 더블 활용 지침 3.3.1 용도에 맞는 더블을 선택하라 3.3.2 준비하고, 시작하고, 단언하라 3.3.3 구현이 아니라 동작을 확인하라 3.3.4 자신의 도구를 선택하라3.3.5 종속 객체를 주입하라3.4 요약 PART 2 테스트 냄새CHAPTER 4 가독성4.1 기본 타입 단언 4.2 광역 단언 4.3 비트 단언
CHAPTER 5 유지보수성 5.1 중복 5.2 조건부 로직 5.3 양치기 테스트 5.4 파손된 파일 경로 5.5 끈질긴 임시 파일 5.6 잠자는 달팽이 5.7 픽셀 퍼펙션 5.8 파라미터화된 혼란 5.9 메서드 간 응집력 결핍 5.10 요약
CHAPTER 6 신뢰성 6.1 주석으로 변한 테스트 6.2 오해를 낳는 주석 6.3 절대 실패하지 않는 테스트 6.4 지키지 못할 약속 6.5 낮아진 기대치 6.6 플랫폼 편견 6.7 조건부 테스트 6.8 요약
CHAPTER 7 테스트 가능 설계 7.1 테스트 가능 설계란? 7.1.1 모듈러 설계 7.1.2 SOLID 설계 원칙 7.1.3 맥락을 고려한 모듈러 설계 7.1.4 모듈러 설계를 위한 시운전 7.2 테스트 불가 원인 7.2.1 클래스 생성 불가 7.2.2 메서드 호출 불가 7.2.3 결과 확인 불가 7.2.4 협력 객체 대체 불가 7.2.5 메서드 오버라이딩 불가 7.3 테스트 가능 설계를 위한 지침 7.3.1 복잡한 private 메서드를 피하라 7.3.2 final 메서드를 피하라 7.3.3 정적 메서드를 피하라 7.3.4 new는 신중하게 사용하라 7.3.5 생성자에서는 로직 구현을 피하라 7.3.6 싱글톤을 피하라 7.3.7 상속보다는 컴포지션을 사용하라 7.3.8 외부 라이브러리를 감싸라 7.3.9 서비스 호출을 피하라 7.4 요약
CHAPTER 8 제2의 JVM 언어를 활용한 테스트 작성 8.1 JVM 언어 혼용의 조건 8.1.1 일반적인 이점 8.1.2 테스트 작성하기 8.2 그루비로 단위 테스트 작성하기 8.2.1 간소화된 테스트 셋업 8.2.2 그루비로 작성한 JUnit 4 테스트 8.3 BDD 도구의 뛰어난 표현력 8.3.1 easyb로 작성한 그루비 명세 8.3.2 테스트의 표현력을 높여주는 스폭 8.3.3 스폭의 또 다른 무기, 테스트 더블 8.4 요약
CHAPTER 9 테스트 속도 개선 9.1 속도 개선을 위해서 9.1.1 더 빠르게! 9.1.2 상황 속으로 9.1.3 빌드 프로파일링하기 9.1.4 테스트 프로파일링하기 9.2 테스트 코드 속도 높이기 9.2.1 피곤하지 않다면 잠들지 말라 9.2.2 덩치 큰 기반 클래스를 경계하라 9.2.3 불필요한 셋업과 티어다운을 경계하라 9.2.4 테스트에 초대할 손님은 까다롭게 선택하라 9.2.5 로컬하게, 그리고 빠르게 유지하라 9.2.6 데이터베이스의 유혹을 뿌리쳐라 9.2.7 파일 I/O보다 느린 I/O는 없다 9.3 빌드 속도 높이기 9.3.1 램 디스크를 활용한 초고속 I/O 9.3.2 빌드 병렬화하기 9.3.3 고성능 CPU에 짐 떠넘기기 9.3.4 빌드 분산하기 9.4 요약
Appendix 부록 Appendix A JUnit 기초 A.1 기본적인 JUnit 테스트 케이스 A.2 JUnit 단언문
Appendix B JUnit 확장하기 B.1 러너를 통해 테스트 동작 제어하기 B.2 규칙으로 테스트 꾸미기 B.3 기본 규칙들
“제품설계가 요구사항에 달아 소스코드로 서로 사맛디 아니할쌔이런 전차로 어린 개발자가 검증하고저 홇배 이셔도마침내 제 뜨들 시러 펴디 몯홇 하니라.내 이랄 윙하야 어엿비 너겨 새로 책 한 권을 번역하노니사람마다 해여 수비니겨 날로 쑤메 뼌한키 하고져 할 따라미니라.”처음 이 책을 접했을 때 가장 먼저 눈길을 사로잡았던 것은 바로 『Effective Unit Testing』이라는 책의 제목과 테스트 가능 설계testable design라는 7장의 제목이었다. 과연 Effective라는 이름을 내걸기에 부끄럽지 않은 책일까? Effective로 시작하는 책 대부분은 유행에 흔들리지 않고 비교적 오랫동안 가치를 인정받는 듬직함을 보여준다. 단순한 따라하기나 기교 중심의 어떻게(how)가 아닌, 주제에 관한 깊은 이해와 오랜 경험으로부터 우러나온 왜(why)를 다루기 때문이다. 왜를 이해한다는 것은 명확한 목적의식을 가지고 행동하게 되며, 변화하는 환경에서도 흔들리지 않는 근본적인 기준에 따라 판단하고 응용할 수 있게 됨을 의미한다. 이러한 관점에서 이 책은 전혀 부족하지 않다고 판단되었고 번역 제안을 수락한 결정적인 이유가 되었다. 개인적으로는 2006년경에 테스트 가능 설계 안티 패턴을 정리하려던 적이 있었다. 홀대받는 테스트가 사실은 제품 설계와 생산성에 큰 영향을 주므로 개발 초기부터 이를 고려하면 전반적인 개발 과정이 훨씬 효율적이고 부드럽게 진행된다는 점을 알리고 싶었다. 당시만 해도 개척할 게 많은 분야였던 터라 잘 다듬어서 저널이나 학술지에 내볼 요량이었다. 하지만 컨설턴트도 아니고 테스트가 주업도 아닌지라 원하는 만큼의 적절한 예제를 모으는 데 한계가 있었고, 결국 어설픈 초안 수준에서 그만두고 말았다. 이러한 개인적 경험 때문에 테스트 가능 설계란 주제는 큰 호기심과 아쉬운 감정을 동시에 불러일으켰다. 그래서 이 책을 통해 내가 정리하던 것과 얼마나 유사한지, 혹은 더 발전했는지 확인해보고 싶었다. 결국, 구성이나 내용 면에서는 많은 차이를 보였지만 큰 그림과 의도는 일맥상통했다. 그래서 이렇게 다른 이의 결실에 편승해서라도 그때 하고자 했던 이야기를 세상에 들려주고 싶다는 동기가 더해졌다.“좋은 설계임을 증명하려거든 자동화된 테스트를 만들어보라!”흔히 실력 좋다고 알려진 개발자 중 많은 수가 무척 복잡하여 어떻게 쓰는지 모르겠는 코드를 내놓거나 겉은 깔끔하나 그 정도가 지나쳐서 내부 동작원리는 알기 어려운 코드를 만들어내곤 한다. 이런 코드는 검증하기 어렵다는 치명적인 단점이 있다. 개발자 자신이 시연할 때에는 잘 돌겠지만 다른 모듈과 통합할 시점이 되면, 혹은 제품이 출시된 후 소비자에 의해 다양한 패턴으로 사용되면서 뒤늦게 문제가 하나씩 터져 나오는 경우가 많다. 단기간에 가시적 결과를 보여줄 수는 있지만 이렇게 발견된 문제는 개발한 당사자가 아니면 쉽게 손대지 못하니 골치 아픈 상황을 낳기도 한다. 이들의 능력을 깎아 내리려는 의도는 절대 아니다. 다만, 한 차원 높은 생산성과 안정된 품질, 그리고 동료 개발자도 쉽게 이해하고 배울 수 있는 코드를 작성하는 쉬운 방법이 있으나 잘 알지 못하는 듯하여 안타까울 뿐이다.그들에게 필요한 것은 테스트에 대한 인식 전환이다. 테스트란 단순한 기능 검증 수단만이 아닌 요구사항을 명시한 문장이요, 모듈과 API 설계 수단이며, 사용설명서이자, 최고의 인수인계/유지보수 자료이기까지 하다. 특히 개발자의 설계역량 면에서 본다면, 디자인 패턴에만 의지하기보다 테스트하기 쉬운 설계를 추구하는 쪽이 훨씬 탄탄한 기본기와 응용력을 길러줄 것이라고 감히 단언할 수 있다. 여러분이 이 책을 테스트 지침서가 아닌 설계 지침서로 받아들이고 잘 따라준다면 어느덧 진일보한 자신의 실력에 놀라게 될 것이다.아무쪼록 독자 여러분께 재미나고 유익한 책이 되길 기원하며, 책 내용 중 혹 궁금한 것이 있거든 wegra.eut@gmail.com으로 물어봐 주시길 바란다. 여건이 허락하는 한 성심껏 답변하도록 노력하겠다.옮긴이_이복연
