김창준 님과 강규영 님께서 예전에(켄트 벡의 TDD 책이 번역되어 나오기 전) 만드신 TDD 강좌 동영상을 신입 사원들과 같이 보는 스터디가 회사에서 있었는데, 지난 주에 스터디 정리 미팅이 있어서 참석했다. 요즘 너무 정신없는 터라 글을 한 번 써보자고 하고는 벌써 일주일이 지났네. 나는 스터디에는 참가하지 못하고 정리 미팅에만 참석했지만 참 의미있는 미팅이었다고 생각한다.
신입사원들이지만 참여하는 프로젝트 성격상 유닛테스트와 약간의 TDD 경험이 있는 사람도 있고 아예 유닛 테스트에 대한 경험조차 없는 사람도 있었다. 아예 경험이 없는 사람인 경우에는 역시나 유닛 테스트나 TDD에 대해서 제대로 파악하지 못했음을 알 수 있었다.
신입사원들이지만 참여하는 프로젝트 성격상 유닛테스트와 약간의 TDD 경험이 있는 사람도 있고 아예 유닛 테스트에 대한 경험조차 없는 사람도 있었다. 아예 경험이 없는 사람인 경우에는 역시나 유닛 테스트나 TDD에 대해서 제대로 파악하지 못했음을 알 수 있었다.
유닛 테스트에 대해서도 모르는데 TDD와 동시에 접하게 되면 완전히 혼란스러운 상황에 처하게 되는 것 같다. TDD의 장점으로 쉽게 얘기할 수 있는 리팩토링 시의 안전망 역할은 사실 유닛 테스트의 장점인데 구분을 못한다든가 하는 것이다.
당연한 일이라고 생각한다. 나도 유닛 테스트라는 개념보다 TDD라는 개념을 먼저 접했다. TDD 책을 처음 읽고 나서 도대체 이게 뭘 어쩌라는 건가 했던 감정이 기억난다. 테스트를 작성한다는 건 뭐고 녹색 막대는 또 뭐고... 그래서 책을 다시 읽으면서 책에 나온 예제를 모두 따라해보고, TDD에 관한 글을 마구 구글링했었다.
그런 의미에서 정리 미팅의 질문 리스트에 포함되었 있던 "유닛 테스팅을 잘 하고 있는 상황을 가정한다면, 거기에 TDD를 더 하면 어떤 효과가 있는가?"하는 질문이 진짜 TDD의 장점에 대해서 묻고 있는 질문이라고 생각한다.
TDD는 유닛 테스트를 좀 더 의미있게 할 수 있는 동기를 제공한다는 점에 의미가 있다는 것이 내가 생각할 수 있는 대답이었다. 유닛 테스트를 먼저 생각하고 작성하게 되므로, 나중에 작성할 때보다 테스트 코드 작성에 대한 저항감이 적다. 버그 수정 시에는 특히 유닛 테스트 코드를 작성하는 일을 잊기 쉬운데, 버그 수정 시에도 버그 상황을 재현하는 테스트 코드를 먼저 추가하려는 생각을 갖게 되어 유닛 테스트 커버리지 유지에 도움이 된다.
좀 궁색한 답변이긴 하다. 질문에서 이미 "유닛 테스팅을 잘 하고 있는 상황"을 가정하고 있는데 나는 "TDD 없이 그게 잘 될리가 없고, TDD가 잘 할 수 있게 도와준다"라고 대답한 셈이기 때문이다.
TDD의 장점에 대해서 구글링을 해보면 좀 더 경험적인 장점들에 대해서 많이 얘기하고 있는데, 아직 경험이 짧아 내가 직접 느낀 장점이라고 할 만한건 이정도 뿐인 것 같다.