저는 프로그래머가 아닌지라, 제가 직접 TDD를 해본 적은 없습니다. 그저 지속적인 통합으로 인한 혜택들을 누리고 있을 따름이지요.

그런데 테스트 주도 개발에 대한 솔직하고 멋진 포스팅이 있어서 제 맘대로 발췌/번역했습니다:


사용자 삽입 이미지
솔직히 말해서 실망했다. 더 크고, 확실한 성과를 기대했던 것이다.

코드의 품질이 나아질 거라고 말했지만, 사실 내 코드의 품질은 더 나빠졌다. (사실은 제대로 읽어보면, 실질적으로 나뻐진 게 아니라, 잘못 사용하고 있던 것들을 들춰내서 표면적으로 나뻐졌다는 이야기가 나옵니다.)

끝내주는 비방(silver bullet) 같은 게 아니었다.

[그러나] 내가 말하고 싶은 것은, 나는 결코 [테스트 주도 개발(이하 TDD)을 하기] 이전으로 돌아가지 않으리라는 것이다.

코드의 품질을 낮아졌지만, 코드에 대한 나의 이해는 높아졌다.

누군가는 이렇게 말할지 모르겠다. "어떤 규칙 같은 걸 만들어서, 네가 변경하는 코드를 제대로 이해하고 있는지 확인하는 건 어때? 그걸 위해서 굳이 TDD [같은 번거로운 것]을 할 필요까지는 없잖아?" 글쎄, 나는 거의 항상 변경하려는 코드를 이해하고 있다고 생각한다. 그런데 그러고 보니까 내가 정말 내가 그러고 있기는 하나? 이게 바로 TDD가 정말 도움이 되는 부분이다.

이것이야 말로, 내가 듣지 못한 TDD의 커다란 장점이다.

출처: 테스트 주도 개발 ,1년째


위의 글에 대한 박일 님께서 코멘트를 함께 보시면 좋습니다.

참고로 위의 Jamie Fristrom라는 양반, 제가 좋아하는 Manager in A Strange Land를 쓰신 분이군요.

Trackback Address :: http://blog.kaykim.org/trackback/230 관련글 쓰기

  1. Subject: Test-Driven Development, A Year Later

    Tracked from 정의의소의 블로그 2007/08/28 07:36  Delete

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

댓글을 달아 주세요

  1. Favicon of http://alones.kr/blog BlogIcon aloens 2007/08/29 08:47 Address Modify/Delete Reply

    안녕하세요. ^^ 경우 형이 인용하던 말이 여기 있었군요. ^^ 경우형 블로그에 다신 댓글들 잘 봤습니다. (댓글 타고 놀러왔스빈다.)

    RSS 가져갑니다~

    종종 놀러오겠습니다~~

  2. Favicon of http://leanu.tistory.com BlogIcon dualistmage 2008/06/11 10:38 Address Modify/Delete Reply

    Test Driven Development 관련 글을 작성하려고 검색하다 좋은 곳을 발견했네요. 회색 박스 부분 인용하려고 하는데 괜찮은지요~!

    • Favicon of http://betterways.tistory.com BlogIcon 김기웅(Kay Kim) 2008/06/13 17:20 Address Modify/Delete

      출처만 밝히신다면 괜찮습니다. 공통 관심사를 갖고 계시다니 반갑네요.
      귀찮지 않으시다면 저도 그 글을 볼 수 있도록, Trackback만 한 번 날려주시면 감사하겠습니다.