
TTD계의 바이블인 켄트벡의 Test-Driven Development라는 책이다.
흔히 TTD라는 방법론은 이 책을 통해 유행됐고 TTD를 하는 사람이라면 꼭 한번쯤은 읽어봐야하는 필독서라고 알려져있다. 이 책은 단순히 "테스트 코드 '작성' 개발"이 아니라 진짜 "테스트 '주도' 개발" 방법론을 알려준다.
TTD는 "테스트 코드를 모두 작성하고 개발을 시작해야한다", "TTD는 시간만 오래 걸리고 쓸모 없는 방법론이다." 등 많은 오해나 도입 논쟁이 있는 방법론인데 이 책은 TTD에 대한 오해를 바로 잡고 TTD의 장점에 대해 잘 설명해준다.
만약 TTD에 경험이 많이 적다면 이 책보다는 최범균님의 "테스트 주도 개발 시작하기"라는 책을 먼저 읽기를 추천한다. 그 책은 좀 더 입문자에게 맞춰져있고 이 책을 처음 읽으면서 가질 물음들에 대해서 "테스트 주도 개발 시작하기"라는 책은 좀 더 상세히 차근차근 설명해준다. 나는 도메인 객체를 가지고 TTD를 하는것이 어색하고 테스트 리스트에서 테스트 우선 순위를 선별하는것이 잘 납득이 가지 않아서 최범균님의 "테스트 주도 개발 시작하기"라는 책을 중간에 읽고 이 책을 다시 읽었다.
나는 이 책을 통해 TTD에 대해 잘못된 지식을 상당히 많이 바로 잡을 수 있었다.
내가 바로 잡은 오해는 E2E 위주의 테스트에서 단위 테스트 위주의 테스트 코드 전환이였다. (물론 E2E, 단위 테스트 모두 진행해야한다.) 첫 회사에서는 E2E위주의 테스트 코드를 작성하고 특정 모듈에 한해서는 단위 테스트를 진행하는 문화가 잡혀있었다. 잘못된 테스트 코드 작성 방법임에도 불구하고 테스트 코드 작성을 오랬동안 진행해보니 테스트 코드 작성에 대한 많은 장점을 누릴 수 있었다. 예를 들면 "사이드 이펙트가 발생했는지 검사하기", "리펙토링을 안전하게 진행하기", "코드 결합에 대한 피드백 빨리 받기" 등등이 있었다. 이러한 장점을 얻었음에도 잘못된 테스트는 개발팀을 힘들게했다. E2E 위주의 테스트 코드는 전체 테스트 코드 수행 시간을 오래 걸리게 하기 때문이다. 그 이유는 DB에 직접 커넥션을 맺으며 데이터를 직접 넣고 수정하기 때문이였다. (전체 테스트 케이스 수행 시간 10~15분 이상) 물론 개발할때는 필요한 테스트만 grep으로 테스트를 수행하니 테스트가 오래 걸린다고 느끼지는 않았지만 전체 테스트 케이스를 돌리는것이 필수 프로세스이였기에 마지막 전체 테스트시 시간이 오래걸렸다. 그렇기 때문에 E2E보다는 단위 테스트를 위주의 테스트 주도 개발을 방식으로 전환했다. DB에 연결되는 부분은 Mock이나 Fake를 이용하여 DB에 직접 연결하지 않고 테스트를 수행하니 수행 시간이 휠씬 빨라졌다.