몇일전 테스트 주도 개발이라는 책을 다 읽었다.

1장부터 16장까지는 은행에서 사용하는 돈(통화)에 관련된 작업을
어떻게 TDD로 만들어 가는지를 실제 코드를 보여주면서 보여주고 있다.

17장 부터는 TDD 자체에 대한 이야기로 되어 있다.

이전에 적었던 부분을 빼고, 책을 읽으면서 줄쳐 놓은 부분을 옮겨 본다.
  • 이러한 접근 방식은 "깔끔한 코드" 부분을 먼저 해결한 후에, "작동하는" 부분을 해결해 가면서 배운것들을 설계에 반영하느라 허둥거리는 아키텍쳐 주도개발과는 정반대다.
  • 시스템이 크다면, 당신이 늘 건드리는 부분들은 절대적으로 견고해야 한다. 그래야 나날이 수정할때 안심할 수 있기 때문이다.
  • "다음에 할일은 무엇인가?"에 관련된 또 다른 질문은 "어떤 테스트들이 추가로 더 필요할까?"다.
  • 그리고 지금 이 글을 쓰는 동안 "Expression(수식)" 메타포를 생각했는데, 설계가 기존과는 완전히 다른 방향으로 흘렀다. .... Expression 메타포는 중복되는 통화를 합치는 세세한 일단의 문제에서 날 해방시켰다. 나는 수식의 성능에 대해 우려 했지만 최적화를 시작하지 전에 어느정도의 사용 통계를 볼때까지 기다리는것에 만족한다.
  • 아주 확신에 찬 사람과 정말 얼렁뚱땅 넘어가는 사람들 제외한다면, 아무리 작은 변화라도 테스트 하지 않고 릴리즈 하지 않는다. ( 만든것만 테스트하는 임시 테스트 코드 )
  • 당신이 변화를 테스트 할 수 있다고 해도, 실제로 변화를 테스트하는 것은 "테스트를 가지고 있다."는 것과 똑같지 않다. ( 계속 유지되는 자동화된 테스트 )
  • 이 경우엔 '테스트'를  '자동화된 테스트'로 치환하면 된다. "내가 이걸 고치면 뭔가 다른 부분을 망가트리지 않았을까?" .... 자동화된 테스트가 있다면 스트레스를 받기 시작할때 테스트를 실행할것이다. .... 테스트를 실행하면 즉시 좋은 느낌을 받게 되고 그러면 작업중에 에허를 낼 일도 줄게 되며, 스트레스도 적어진다.
  • 테스트를 실행하는 것이 서로 어떤 식으로 영향을 미쳐야 좋은가? 아무 영향이 없어야 한다. .... 앞 부분에서 실행된 테스트가 실패한 후 그 영향으로 다음 테스트부터는 시스템이 예측 불가능한 상태에 놓이는 경우가 허다하다.
  • 테스트는 전체 애플리케이션을 대상으로 하는것 보다 좀 더 작은 스케일로 하는것이 좋다. 어쨌건 주된 교훈은 각각의 테세트는 다른 테스트와 완전히 독립적이어야 한다는것이다. 즉, 문제가 하나면 테스트도 하나만 실패해야하고, 문제가 둘이면 테스트도 두개만 실패해야 한다.
  • 테스트를 언제 작성하는것이 좋을까? 테스트 대상이 되는 코드를 작성하기 직전에 작성하는것이 좋다. 코드를 작성한 후에는 테스트를 만들지 않을것이다.
  • 시스템을 배갈할 때 무슨 일 부터 하는가? 완료된 시스팀이 어떨 거라고 알려주는 이야기 부터 작성한다. ( USER STORY를 말한다. 기존의 방법론의 요구사항 문서와 비슷한데 훨씬 짧고 비격식적이다. )
  • 테스트 할 때 어떤 데이터를 사용해야 하는가? 테스트를 읽을 때 쉽고 따라가기 좋을 만한 데이터를 사용하라. .... 1과 2 사이에 어떠한 개념적 차이도 없다면 1을 사용하라.
  • 시스템이 여러 입력을 다루어야 한다면 테스트 역시 여러 입력을 반영해야 한다.
  • 길을 잃은 느낌이 들땐 어떻게 해야 할까? 코드를 다 지워버리고 처음부터 다시 해 보자.

더 많은 내용에 줄을 그어 놓았지만, 그만 옮겨적어야겠다.


아직은 "테스트 주도 개발"에서 "테스트"에 대해서만 와 닿았고, "주도"에 대해서는 잘 모르겠다.
다음에 정리를 다시하면서 "주도" 부분도 다시 한번 알아 봐야 겠다.
신고
  1. leonid 2008.03.19 19:01 신고

    안녕하세요. 이번에 TDD에 대해서 공부를 시작해보았습니다. 아직까지는 온라인에 있는 글과 동영상들만 봤지만 역시 책을 사서 읽어야 할 것 같네요 :)

    • Chan 2008.03.19 22:34 신고

      어이쿠~ 답변 감사합니다. ^_^

      제가 내린 결론은
      TDD는 아직잘 모르겠지만, 확실히 느낀건 TestCase는 많으면 많을 수록 좋다 였습니다. ^_^

이번에 책을 무려 3권이나 구입했는데, 그 중에 하나.

  테스트 주도 개발  켄트 벡 지음, 김창준 외 옮김
최근 학계와 업계에서 많은 주목을 받고 있는 프로그래밍 방법인 '테스트 주도 개발(Test-Driven Development)'에 대해 설명한 책이다. 테스트 주도 개발을 퍼뜨린 장본인이며 객체 지향 프로그래밍의 선구자 중 한 사람인 켄트 벡이 직접 서술했고, 부록에는 TDD 시연 동영상을 수록했다.



지금은 겨우 서문을 다 읽고 1부의 1장을 아주 조금 읽었다.
실제 내용은 겨우 5-6페이지 읽었을 뿐이다.

책의 앞에는 옮긴이의 서문과, 옮긴이가 쓴 TDD 수련법, 옮긴이와 글쓴이의 인터뷰내용이 들어 있다.
이 내용은 테스트주도개발을 처음 접하는 독자들에게는 그렇게 크게 느낄만한 내용이 없다.

처음 읽는 사람은테스트 주도 개발이 뭔지도, 왜 필요한지도 모르기 때문이다.


저자의 글에서 몇가지 정리하면..

. 매 결정사항에 대해 피드백을 제공하는 실행 가능한 코드를 기반으로 하는 유기적인 설계를 해야 한다.
. 테스트를 쉽게 만들려면 반드시 응집도는 높고 결합도는 낮은 컴포넌트들로 구성되게끔 설계해야 한다.

| 용기 |
두려움이란 나쁜 의미의 - 무서워요. 프로그래머는 젖꼭지가 필요해요 - 두려움을 뜻하는 것이 아니고, "정말 어려운 문제라서 시작 단계인 지금은 어떻게 마무리될지 알 수 없군" 하고 생각하는 식의 합리적인 두려움을 말한다.

. 두려움은 여러분을 망설이게 만든다.
. 두려움은 여러분이 커뮤니케이션을 덜 하게 만든다.
. 두려움은 여러분이 피드백 받는 것을 피하도록 만든다.

프로그래밍 문제가 어려울수록 각각의 테스트는 좀 더 작은 부분을 커버해야 한다.

순수하게 TDD로만 풀어낼 수는 없는 프로그래밍 작업이 분명히 있을 것이다( 혹은 최소한 아직까지는). 예를들면 보안 소프트웨어와 동시성(concurrency)은, TDD로 해당 소프트웨어의 목표가 달성되었다는것을 기계적으로 보여주기에 부족한 두 가지 주제라고 할 수 있다.

설계는 반드시 잘 되어야 한다. 그렇게 해야만 Test를 이용해서 개발하기가 쉬워진다. 즉, 테스트가 설계를 잘 하도록 도와주지는 않는다. 그렇기 때문에
설계가 우선 되어야 한다.



들어가는 글에서..
"... 하지만 미합중국 달러로 명명된 채권만 다루더군요. 저는 새로운 채권 펀드를 시작하려고 하는데 제 전략상 다른 화폐로 채권을 다룰 필요가 있습니다." 라고 했다. 보스가 워드를 돌아보며 말했다. "저기, 우리가 그걸 할 수 있을까요?"
이것이 바로 어떤 소프트웨어 개발자에게든 악몽이 될만한 시나리오다. 당신의 몇가지 가정하에 성공적이고 행복하게 순항하고 있었는데 별안간 모든것이 바뀌었다.

.....

그날 하루가 끝나갈 즈음에는 테스트가 전부 통과했다. 워드는 코드를 빌드에 체크인하고 보스를 찾아갔다. "할 수 있습니다.", 그는 확신에 차서 말했다.

이 이야기에 대해 조금만 생각해보자. 이틀 만에 잠재적 시장이 몇 곱절이나 커졌고 덕분에 와이캐시의 가치 역시 몇 배 늘어났다. 하지만 그렇게 빨리 그토록 많은 비즈니스 가치를 만들어내는 능력은 우연이 아니었다.


저기에서는 저기 빨간 말이 진짜 마음에 와 닿는다.

당신의 몇가지 가정하에 성공적이고 행복하게 순항하고 있었는데 별안간 모든것이 바뀌었다.

대충 요렇다~


딱 요만큼만 보고, 충분히 -_- 필요하다고 공감했다.
신고

+ Recent posts