TDD가 어떻게 개발의 엔트로피를 낮추는가

사실상 시도는 전에 전 프로젝트에서부터 였습니다.  안타깝게도 한 프로젝트는 매우 단명하였고, 다른 하나는 상용엔진에 스크립트 기반 작업이 대부분이라는 핑계로 테스트를 등한시 하였습니다. 최근 간신히 둥지를 튼 새 회사에서는 나름 의욕적으로 TDD(Test-Driven Developement)를 추진하였습니다.

아직도 갈 길이 구만리이지만, 이제 그 기반은 어느 정도 자리를 잡은 듯 합니다. 아쉽게도 아직 test-first의 경지에 이르지는 못했습니다. 비록 선작업이 아닌 후작업으로 테스트 코드를 짜고는 있지만, 벌써 그 장점이 드러나더군요(참고로 저희는 boost library를 적극 활용하고 있어, 단위테스트 프레임워크도 거기 있는 것을 사용하였습니다).

첫째는 훌륭한 예제 코드로서의 기능입니다. 저희는 코드 리뷰를 의무화하고 있습니다. 주석이 어느 정도 잘 달려 있어도 남의 코드를 읽는 것이 간단한 일은 아니죠...(참고로 저희는 CodeStriker라는 오픈소스 코드 리뷰 툴을 사용 중인데... 버그도 많고 사용도 어려워 다른 놈으로 갈아타려고 합니다.) 이 때, 테스트 코드가 예제로서 코드의 의도를 명확히 하여 이해를 돕습니다.

둘째는 개발 엔트로피의 통제 기능입니다. 저는 코드를 짜고, 컴파일을 성공시키고, 실행 파일을 돌려서 아무 에러가 없으면 1차 기능 구현이 완료되었다고 판단하는 안일한 습관이 있었습니다. 설사 방금 짠 기능을 제대로 활용하고 있는 부분이 아직 코드에 없더라도 말입니다!

이럴 경우 나중에 다 구현되었다고 생각한 모듈들이 실제 통합되어 제 기능을 하게 되는 시점에 파국을 맞게 되지요... 안일한 판단 속에 개발 엔트로피가 싸여가고 눈덩이처럼 불어나다가... 나중에 펑! 또 마일스톤을 놓쳤군요. 단위테스트는 애초에 의도한 모듈의 기능을 가능한 한 빠른 시점에 검증하게 함으로써 개발 엔트로피가 과도하게 쌓이는 것을 막아 줍니다.

이외도 많은 장점이 있겠으나, 일단 개발 초기인 현 시점에서 가장 마음에 와 닿는 것을 공유해봅니다.
크리에이티브 커먼즈 라이선스
Creative Commons License
Trackback 0 Comment 0

top