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 ]

Extremely Agile/General2007.09.18 15:44

Extreme Programming에 관해 최근 이 책 저 책 열심히 보고 있습니다만.

Extreme Programming 혹은 Agile 방법론을 능숙하게 실행할 수 있거나 혹은 그 절차를 능숙하게 정의내릴 수 있는 프로그래머 혹은 아키텍트가 되려면, 대체 무엇을 알아야 하느냐. 이런 의문이 생기더군요.

그래서 몇 가지를 정리해봤습니다.

  1. 기술에 대한 열린 마음가짐 - 어떤 형태의 기술이던 열린 자세로 받아들이겠다, 는 마음가짐이 정말 중요한것 같습니다. 이런 자세가 없는 프로그래머는 어디서 일해도 실패하기 딱 좋습니다.
  2. 사람에 대한 열린 마음가짐 - 주변 사람들이 전부 자기와 같은 가치를 갖는 사람이라는 마음가짐을 가지고, 존중하는 자세가 필요합니다. 이런 자세가 없으면 왕따당하기 딱 좋지요...
  3. 기본적인 기술들에 대한 지식들 - 이런 지식들로는 뭐가 있을까요? 간단하게 꼽아보면 얼핏 생각나는 것만해도 UML, CVS, C++, Java, Design Pattern, Refactoring, Make, Ant, TDD, jUnit, CppUnit 등등이 있군요. 여기서 제가 잘 모르는 거로는 Ant가 있네요. -_-;

사실 UML과 C++, Java에 대해서는 오래 전부터 알고 있었습니다만, Design Pattern이나 Refactoring 기법, CVS에 대해서는 공부하기 시작한지 일년 남짓밖에 되질 않습니다.

하지만 개발을 진행하면 할수록, 상대적으로 저수준의 기술(C++, Java 등, 프로그래밍 언어레벨의 기술)보다는 그 상위의 개념에 대한 지식이 보다 절실하게 느껴지더군요. 사실 Extreme Programming에 사용되는 기술들은 프로그래밍 언어보다는 추상화 레벨이 높습니다. UML 같은 것은 'Language'라고는 하지만 실제로 구현될 시스템을 기술하는 기호언어에 가깝고, Design Pattern이나 Refactoring같은 기술들은 어떤 언어에도 적용될 수 있는 중립적인 기술이라 (물론 적용 형태는 언어에 따라 조금씩 달라질 수 있겠습니다만) 저수준의 지식이라고 하기는 힘들어요.

아키텍트라고 불리는 사람들에게 요구되는 것이 프로젝트 관리 능력이라고 본다면,  그런 역할을 맡는 사람들은 저수준의 프로그래밍 언어뿐 아니라, 보다 추상화 정도가 높은 언어(그런 언어들을 메타-프로그래밍 언어라고 부를 수 있을까요?)에도 능통할 필요가 있습니다. 사실 아키텍트는 단순한 개발자(주로 프로그래밍 언어만을 사용하여 소통하는) 뿐 아니라 다른 팀이나 고객들과도 소통을 할 의무가 있거든요. 그런 사람들에게 프로젝트의 궁극적인 지향점을 설명하려면, 보다 추상화 정도가 높은 언어로 개념을 다듬는 것이 필요하다는 거죠.

좀 일찍 이런 생각을 했으면 공부를 더 열심히 했을텐데... ㅋㅋ

최근에 관련해서 읽고 있는 (혹은 다 읽은) 책들은 다음과 같습니다.

  1. 익스트림 프로그래밍
  2. 사용자 스토리
  3. 린 소프트웨어 개발
  4. 테스트 주도 개발
  5. 실용주의 프로그래머
  6. 실용주의 프로그래머를 위한 버전 관리
  7. Java 프로그래머를 위한 UML, 실전에서는 이것만 쓴다

책을 안읽은지 너무 오래되어서 -_- 여러 책들을 한꺼번에 읽으려니까 좀 정신사납긴 하군요. ㅋㅋ



신고
Posted by 이병준

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

  1. 안녕하세요!!! 좋은 글 감사합니다. 자주올게요!!

    2011.01.28 01:15 신고 [ ADDR : EDIT/ DEL : REPLY ]