Extremely Agile/TDD2007.09.23 20:45

아래의 그림은 TDD를 사용한 개발을 수행하는 절차를 요약하고 있습니다.

원본은 여기에 링크 걸어둔 PDF 파일에 나옵니다. 하도 예전에 다운받아둔거라 언제 받았는지도 기억이 잘 나질 않습니다만, PDF 파일을 열어 보면 어디서 다운받은 것인지는 나오는군요. :-) 참고하시기 바랍니다.

나온지 좀 오래된 자료이기는 합니다만, TDD의 개발 절차라는 것이 TDD 개념이 등장한 이래로 그렇게 많이 바뀌거나 하지는 않았습니다. 코드 작성 전에 테스트를 먼저 한다, 는 원칙은 그대로 있고, 그 적용에 따르는 세부사항만 좀 바뀐 정도일텐데, 그 나마 큰 변화가 있는 것 같지는 않아요.


사용자 삽입 이미지



절차는 간단히 요약하면 이렇습니다.
  1. 테스트 리스트를 만듭니다. (어떤 테스트를 수행할 것인지 협의하는 과정에서 나옵니다. 사용자 스토리를 만드는 과정에서 도출되는 일이 많습니다.)
  2. 다음의 3~7까지를 계속 반복합니다.
  3. 테스트 리스트에서 테스트 하나를 고릅니다.
  4. 우선, 컴파일조차 되지 않는 테스트 코드를 작성합니다. (컴파일이 되지 않으니 테스트를 아예 할 수가 없습니다.) [위의 다이어그램에서는 위에서 두 번째 줄의 왼쪽에서 두 번째 박스]
  5. 대충 뜯어 고쳐서 컴파일은 되도록 만듭니다. 테스트는 당연히 실패할 것입니다.
  6. 그런 다음, 우선 테스트가 통과되도록 만듭니다. (테스트가 통과되도록 만드는 것이 목적이니, 코드에 hardwired 된 로직이 존재해도 아직은 상관이 없습니다. 가령, 3이라는 반환값을 요구하는 테스트라면, 함수 안에서 그냥 3을 리턴해도 이 단계에서는 상관이 없다는 말입니다.
  7. 그런 다음 리팩토링(refactoring)을 시작합니다. 리팩토링을 해나가면서 중복을 제거하고, 말이 안되는 부분을 하나씩 말이 되도록 만듭니다. 리팩토링은 '아주 작은 단위'의 코드 변경입니다. 코드가 변경될 때 마다 컴파일하고 테스트를 돌려서, 그 리펙토링이 테스트를 fail시키지 않는지 확인해야 합니다. fail시켰다면, 너무 작은 리팩토링을 시도했거나, 잘못된 리팩토링 - 즉, 논리적인 오류를 발생시킨 리팩토링을 했다는 뜻입니다. 위의 그림에서는 '리팩토링'->'테스트' 사이의 순환 관계가 명시적으로 드러나지는 않습니다만, 리팩토링과 테스트는 반복적으로 계속해서 해나갈 수 있습니다.
뭐, 그림 자체는 그런 뜻입니다. :-) 그럼 테스트는 대체 어떻게 만드느냐.

이상적으로 보자면 테스트가 '개발될 모듈이 가져야 할 이상적인 인터페이스'에 근거해서 만들어지는 게 가장 좋겠지만, 그렇게 하자면 머리속에 '개발될 모듈의 형태'가 우선 잡혀야 합니다.

TDD 개발 과정에 대한 책 ("테스트 주도 개발") 을 보신 분이면 아시겠지만 테스트는 고정적이 아니며 항상 변화합니다. 개발될 모듈의 형태가 어떠할 지 완벽하게 미리 예측하는 것이 불가능하기 때문입니다. 테스트를 하고, 중복을 제거하고 리팩토링을 하다보면 개발중인 클래스가 개발자가 예측한 것과 조금은 다른 방향으로 흘러가게 되는 일도 생길 수 있고 (물론 가급적 그렇게 되지 않는 것이 좋겠지만 말입니다) 다른 식으로 구현을 가져가는 것이 보다 효율적이겠다는 판단을 내리게 되는 일도 생길 수 있습니다.

그러니, 테스트를 '미리 잘 정돈하여 만들어두어야 겠다'는 생각은 버리는 게 좋겠습니다. '어떤 테스트를 해야 하느냐'는 고정적일 수 있지만, '테스트를 어떻게 해야 하느냐'는 것은 계속해서 달라질 수 있기 때문입니다.
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. TDD를 적용하기 위한 절차를 찾다가 발견하게 되었습니다. 많은 도움 얻고 갑니다...
    즐거운 하루되세요~^^

    2008.04.22 11:38 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. TDD를 하면서 느끼는 것은 초보자 무리라는 것입니다. ^^ 제가 생각하기에는 그래요.
    일단 초보자는 상급자로부터 Requirement를 받기 때문에 상당히 제한적이고, 초반에 참여를 하더라도 경험이 적기 때문에 테스트 코드를 많이 못 만들어 내는 것 같습니다.
    또한, 초보자는 Refactoring을 해야할 때, Refactoring 자체에 대한 지식이 별로 없는 관계로 힘들고 때에 따라서 Design Pattern을 적용해야 할 때가 있는데, 그렇지 못 할 때도 있더군요. 또 Design Pattern을 몰라도 되지만, 바라던 최적화 코드는 그다지 나오지 않더라구요.

    하지만, 지속적으로 이렇게해서 개발경력을 쌓으면 무적이 될 것 같기도 하네요. 그래서 저도 TDD를 지향합니다.

    Rod Johnson의 인터뷰인가? 정확하게 기억나지는 않지만, 꼭 필요한 기술이라고 해서, 1. OFD(Oriented Framework Development), 2. DI & IOC, 3, TDD 등이 있었던 것 같네요.

    잘 읽고 갑니다.

    2008.06.11 15:05 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 반갑습니다. 초보자에게 좀 무리일 수는 있습니다만, 그 과정을 통해 배우는 것이 많다는 점에서 긍정적일수도 있을 것 같습니다. 저는 TDD를 최근에야 접했는데, 제가 통상적으로 프로그램을 짤 때 거치는 과정과 많이 닮아있어 오히려 프로그래밍을 배우기 시작하는 초기에 배웠더라면 어땠을까, 하는 생각을 자주 했습니다.

      2008.06.12 14:30 신고 [ ADDR : EDIT/ DEL ]