기본이 바로 선 나라

어제 SQE 업무를 함께하고 있는 팀원들과 이런 저런 이야기를 하다가 TDD가 진짜로 필요한지에 대한 논의(논쟁?)을 잠시 했다. 그 중에는 개발 경험이 많은 친구도 있었고 그렇지 않은 친구도 있었다.
 - 필요하다.
 - 필요없다.
 - 바쁘면 일단 구현하고 나중에 시스템 테스트를 하는 게 더 효율적이다.
 - 정답은 없다. 팀 상황과 능력에 따라 다르다.
이런 내용들이었지만 담배피는 잠깐동안의 이야기였기 때문에 이렇게 정리가 되었다.

우선 나는 어떠한 형식이던지 테스트는 꼭 필요하고 TDD는 그 중 개발팀에서 주도적으로 할 수 있는 훌륭한 것 중의 하나라고 생각한다. 즉, 나는 믿는다. 이제 그 필요성을 사람들에게 느끼기 해 주기 위해서 앞 선 글에서도 이야기했지만 좀 더 깊게 공부와 사례 연구를 해서 Expert가 되고 싶은 거다.

TDD에 대해서 경험에 의한 솔직 담백 글이 있다. 기대도 이야기했지만 이런 변화를 SE, SQE팀에서 주기는 힘든 것 같다. 조금 더 내공을 쌓은 후 개발팀으로 복귀하는 것이 좋겠다는 생각을 다시 한 번 해 본다. 그러나 현재의 팀(SQE)에서도 얻는 것은 많다. 다양한 개발팀을 만날 수 있다는 것이다. 연구 과제, 상품과 과제, 프로세스를 잘 따르는 팀, 마구잡이? 개발 팀 등… 많은 사례를 볼 수 있는 것이 장점이다.

저는 프로그래머가 아닌지라, 제가 직접 TDD를 해본 적은 없습니다. 그저 지속적인 통합으로 인한 혜택들을 누리고 있을 따름이지요.
 - 김기웅님의 “테스트 주도 개발 ,1년째” 중

하지만, TDD 를 하기 위해서 테스트 코드를 짜다보면
‘내가 제대로 이해하지 못한 상태로 필요한 코드를 copy & paste 해서 쓰고 있었구나’ 라는 느낌을 받게 됩니다.
그리고 원하는 부분을 집중 연구해 보기가 훨씬 쉬워집니다.
마치 실험실 속에 가운을 입고 연구하고 있는 듯한 느낌이 들기도 하죠.
그리고 원하는 코드를 break point 걸고 싶을 때도
간단하게 테스트 코드만 추가함으로서 몇 초안에 각 변수들이 실행시점에 어떤 값을 가지는지를 눈으로 직접 확인할 수 있습니다.
 - 박피디님의 “Test-Driven Development, A Year Later” 중

나는 아직 그런 혜택도 못 받았고 그런 경험도 없지만 믿고 더 깊게 파고 들어 봐야겠다.