내가 생각하는 TDD

정상혁정상혁

image

(이미지 출처: http://www.flickr.com/photos/titicat/2986232393/ )

"컴퓨터가 내 의도를 이해했는지 표시하는 신호등을 설치하고, 그 신호에 의지해서 사람이 더 읽기 편하고 고치기 쉬운 코드를 개발하는 기법입니다.

처음에는 내가 만드는 프로그램 조각이 어떤 상황에서 어떤 결과를 내는지 설명하는 글을 씁니다. 이 것을 명세나 테스트라고 부르는데, 그 것도 컴퓨터가 해석하고 실행가능한 형식으로 만듭니다. 그 설명을 컴퓨터가 실행해서 조건과 결과가 의도한대로 되었는지 신호등으로 알려주게 합니다.  다음에는 그 설명과 맞아떨어지는 코드를 작성합니다. 신호등은 파란색이 되었다면  코드에 실린 사람의 의도를 모두 컴퓨터가 잘 받아들였다는 의미입니다. 파란색은 다음 발걸음을 내딪을 수 있다는 신호이기도 합니다.

컴퓨터를 이해시킨 다음에는 사람이 더 편안하게 볼 수 있는 코드로 다듬어야 합니다. 다시 코드를 보는 사람이 헷갈리지 않도록 중복을 없애고, 코드의 의도를 더 확실하게 표현하도록 이름을 바꾸거나 프로그램 조각의 일부를 빼내서 정리합니다. 충분히 자신이 있어서 처음부터 컴퓨터와 사람에게 모두 충분한 코드를 만들었다면, 발걸음을 크게 해서 바로 그 다음 설명과 신호등을 만듭니다. 교통 신호등처럼 시간이 고정되어 있지 않고, 신호 사이의 간격, 신호등이 확인하는 설명의 크기와 다음 신호등을 만드는 시기을 마음대로 조절해도 됩니다. 그런데 하다보면 자주 파란불을 보고 싶어서 간격을 짧게 만들고 싶어집니다.

이런 과정을 거치다보면 여러 가지를 얻습니다. 신호등이 연결된 설명서는 컴퓨터와 사람이 모두 이해할 수 있는 문서입니다. 그리고 잘 설명되고, 검증될 수 있는 코드들은 역할과 책임이 명확해서 다음에 기능을 추가하거나, 수정을 할 때 더 적은 노력이 들어갑니다. 중간 중간 내부에 설치된 신호등을 한꺼번에 켜보면 엑스레이 사진처럼 프로그램 속이 들여다 보입니다. 깊숙히 박혀 있는 오류를 찾아내는 시간도 줄여줍니다. 무엇보다 빨간 불, 파란불을 왔다갔다 하다보면 프로그래밍이 더 역동적인 일이 됩니다. 컴퓨터와 반응을 주고 받는 것이 마치 게임과 비슷해 집니다. 파란불을 볼때마다 뭔가 끝을 내고 성취했다고 느껴지고 칭찬을 받는 기분으로 그 다음 작업을 할 수 있는 힘을 얻습니다. 그래서 프로그래밍이 더 재미있어지고, 집중도 잘 됩니다. "

신입사원 교육을 하면서 주로 유명인들이 이야기한 TDD의 여러 측면들을 인용해서 설명을 했습니다. 그런데 정말 저만의 단어로 TDD를 설명한다면 어떻게 할까. 스스로 궁금해졌습니다. 적고 나니 계속 다듬어야할 것 같네요.