[TDD] Test Driven Development

테스트 주도 개발 - 켄트 벡 지음, 김창준 외 옮김/인사이트

저자가 워낙 유명하고 김창준님도 번역을 잘하시는 분이라서 작심하고 봤는데 역시! 괜찮은 책이었다. 초보 개발자 티를 벗고 코딩의 생산성을 높이기 위해서 가장 중요한게 테스트가 아닐까 한다. 그것도 그냥 테스트가 아니라 프로그램이 변경되었을 때를 대비한 기민한 테스트.

TDD 는 테스트로부터 프로그램이 만들어져야 함을 말한다.

항상 "이것은 어떻게 테스트 할 것인가?"를 염두에 두고 프로그램을 코딩하라는 것이다.

처음에는 반신반의 했다. 코딩 스타일을 말하는 것이려니 생각했지만 스스로 TDD를 연습해보니 그 효과가 놀라웠다.

내가 TDD를 선호하게된 이유는 인터페이스를 잡아내는데 큰 도움이 되기 때문이다.

프로그래밍 개발은 서비스 행위라고 생각한다. 내가 만든 클래스, 컴포넌트는 반드시 누군가에 의해 사용되기 위해 존재한다. 따라서 내 컴포넌트를 사용하는 쪽의 시각에서 컴포넌트나 클래스가 만들어져야 한다는 것인데 이는 사용자(내 컴포넌트의 서비스를 받는 쪽) 의 편이성을 고려해야 함을 말한다.

TDD에서의 테스트 클래스가 바로 내가 개발하는 컴포넌트의 첫번째 고객인 것이다!!!!

이 고객의 눈높이에 맞춰서 내 컴포넌트의 인터페이스가 변경되고 변경된 인터페이스에 따라 내부 구현이 바뀌어간다. 이를 통해서 검증된 컴포넌트가 도출된다는 점에서 TDD는 개발자들이 어느정도 따라줘야하는 패러다임이 아닌가 한다.

특히 우리나라처럼 전문적인 테스터가 없는 현실에서 개발자가 테스트까지 도맡는 일은 비일비재하다. TDD는 이런 현실에서 효율성과 생산성을 높이는데 부합한다고 생각한다.

이 글을 쓴 이후 코딩을 하면서 "테스트 먼저"를 마음속에 되뇌여 보지만 쉽지가 않다. 몸에 베어들어서 습관으로 굳히지는 못한 단계인듯. 게다가 DB 테스트라든가 네트워킹 연결, 해제처럼 이기종 시스템의 장벽을 넘어서 테스트하기란 웬지 익숙하지가 않다(순전히 경험 부족인듯.-_-;). 관련 프레임워크들이 많이 나오고 있으니 시간의 압박(또는 게으름)때문에 나의 것으로 만들지 못하고 있는 상황이다.

테스트주도 개발, 이것은 결국 얼마나 습관화하는가에 성패가 달렸다고 생각한다.