원래 설 연휴, 그저께부터 오늘까지 3일에 걸쳐서 TDD도 해보고 일지도 3부작으로 쓸 계획이었으나. 게으름과 몇가지 이유때문에 오늘 하루만 TDD 체험을 하게되었다.
오늘 하루, TDD를 하며 다음과 같은 점을 느꼈다.
뭐든 쉽게 질리는 내가 키보드를 비교적 오래 잡고 있을수 있었던건 짧은 테스트 주기와 코드 수정덕분이었다. 평소에는 완벽주의에 찌들어 실컷 생각만하다 지쳐 키보드에서 손을 떼어버렸는데, 테스트 주기와 코드 수정을 짧게 유지하라는 것과 테스트를 만족시키려 할때는 테스트를 빠르게 통과할지도 모르는 가장 간단한 방법을 쓰라는 것이 큰 도움이 되었다. 간혹 테스트보다 먼저 코딩하려는 스스로에게 어짜피 고칠 코드라면 너무 완벽하게 짤 필요는 없다며 손가락을 멈추게 하기도 했다. 완벽한 설계에 대한 걱정은 단순히 기우일 뿐이다. 여러 TDD 관련 글에서도 볼수있다시피 TDD에서 테스트란 일반적으로 말하는 테스트가 아니라, 행동 명세다. 내가 생각하는 행동 양식을 테스트 코드로 표현하고, 거기에 맞추어 구현하면 된다. 물론 행동 명세가 자세할수록 자신이 원하는 구현에 근접하게 될터이니 테스트를 잘 작성하는것이 중요하다.
간혹 몇몇사람들은 TDD를 하면 막무가내 디자인이 나오는게 아니냐고 하지만, 그건 틀린말이다. 코드는 한번 짜고나면 건드리지 않는 존재가 아니다. 코드는 끊임없이 리팩토링 해야한다. 좋지 않은 냄새가 나던 디자인도 테스트가 추가되고, 리팩토링을 하면서 훨씬 좋아진다. 에러가 발생될까 하지 못하던 리팩토링도 테스트코드가 있기 때문에 부담이 확 줄어든다. 이런 과정을 통해 코드는 훨씬 나은 디자인으로 수렴해간다.
그러나 양이 있으면 음도 있는법. TDD 체험을 진행하며 나에게 Alt+Tab을 누르게 한 요인들은 다음과 같다.
내가 원하는 명세를 생각하는것도 문제였지만 제일 큰 문제는 원하는것을 테스트로 어떻게 나타내야할지 모를때였다. 개체 내부에 있는 배열에 값을 복사할때, 할당한 메모리 영역을 넘는지 안넘는지 알게 뭔가! 그래서 버퍼에 값을 넣을때 얼마만큼 소스에서 복사했는지 리턴하도록 추가하고, 새로운 테스트를 작성했다. 문제는 해결했지만 영 찝찝한것이, 이게 TDD에서 말하는 테스트가 용이한 디자인인지 아닌지 헷갈리거니와 테스트간에 의존성이 생긴다는 것이 영 맘에들지 않았다. 이처럼 테스트와 디자인 모두 TDD에 내맡길수 있는것이 아닌, TDD는 그저 보조 도구라는것을 실감하게 되었다. 처음 TDD를 시도하는 나에겐 좀 버거운감이 있었다.
이러니 저러니 말은 했지만 처음 해보는 TDD는 꽤 괜찮은 느낌이다. 이런 느낌으로 코딩해본게 얼마만인지 모르겠다. 지금 하고있는 IRC 데몬 프로젝트는 앞으로도 계속 TDD로 진행해 나갈것 같다.