http://agile.egloos.com/5299932 에서 인상적인 것은 TLP.

조금 특이할만한 것으로 테스트 주도 개발(TDD)과 코딩 후 자동화된 단위 테스트 붙이기(TLP)를 구분해 놓았는데,  TLP는 테스트를 먼저 만드는 TDD와 달리, 코드가 만들어진 후에 그에 대한 자동화된 단위 테스트를 붙이는 것을 말합니다. 레거시 코드가 있는 경우 혹은 TDD를 하기에는 아직 수련이 충분하지 못한 경우 TLP를 하는 조직을 종종 봤고, 저 역시 맥락에 따라 TLP을 우선적으로 권하기도 하기 때문에 TLP를 따로 구분했습니다

코딩 후 자동화된 단위 테스트 붙이기(TLP), 지속적 통합(CI), 고객 참여(CP)가 성공과 관련이 깊습니다.

실천법 중에서 비교적 성공과 직결되는 것들이 존재한다. 그것은 고객 참여, 리팩토링, 코딩후 자동화 단위테스트 붙이기, 코드 공유 등이다.

TDD와 TLP를 구분해 놓았다는 것이 정말 맘에 든다. 단위테스트, 회귀테스트, 시스템테스트, 자동화 테스트, TDD 등을 마구 뭉뚱그려서 설명하고는 TDD 라고 얘기하는, 사실은 MTDD(뭉뚱그린 TDD)로 인해서 개발자들이 혼란과 오해에 시달리지 않게 하는 것은 중요한 것 같다.

최근에 요청 받은 한 인터뷰에서 나는 후배들에게 TDD를 소개하기는 하지만 권장하지는 않는다고 답변했다. 일단은 자신이 만든 코드에 대해서 자동화된 테스트 코드를 잘 작성하는 것이 중요하다고 생각한다. TDD는 스스로 자동화된 단위 테스트의 가치를 진심으로 느꼈을 때 시작해도 늦지 않을 듯.

그런면에서 별로 좋아하는 사람은 아니지만, TestNG를 만든 Cedric이 극렬 TDD 순수주의자인 밥 삼촌의 TDD 3원칙과 같은 글에  "테스트를 나중에 만드는 게 뭐가 어때서? 테스트를 잘 만드는 것이 중요한 게 아닌가?"라고 반박하는 글을 달곤 하는 것을 보면 쪼금 동감한다.

그러고 보니 생각나는데, 전에 블로그(blog.objectmentor.com/)에 TDD를 변호하는 글을 쓰면서, TDD로 만들어진 제품의 하나로 스프링 프레임워크를 들었는데, 미안하지만 스프링은 거의 대부분 테스트를 코딩 후에 만들면서 개발된 것이다.   따라서 밥 삼촌의 TDD 1원칙(테스트를 성공시키기 위해서가 아니라면 코드를 만들지 않는다)을 위반한 것이다. 따라서 스프링은 TLP라면 모를까 TDD로 개발한 사례로 들기는 부적당하다. 이는 스프링 소스코드의 테스트 코드를 봐도 충분히 알 수 있고, 유겐 휄러한테 직접 확인해본 것(만나자마자 이것부터 물어봐서 좀 미안하긴 했지만)이기도 하니 확실하다. 물론 로드 존슨은 일부 스프링 코드 개발은 TDD로 했다고 얘기한 적이 있으니 전혀 없는 것은 아니겠지만. 그래도 TDD로 개발된 제품 사례로 들기는 부적당하다. MTDD라면 모를까.

그런데 TLP는 무슨 약자인가? Test Last까지는 짐작이 가는데.. P는 뭐지. 구글 검색을 해봐도 나오지 않는데. "코딩 후 자동화된 단위 테스트 붙이기"라는 오해를 방지하기 위해 상당히 꼼꼼한 이름을 붙인 것을 보아서는 꼼꼼하기로 유명한 김창준님이 직접 만든 용어라는 의심이…

Related posts:

  1. 테스트 주도 개발 TDD 실천법과 도구 – 채수원
  2. 오픈소스 소프트웨어에서 오픈소스 코드가 가지는 의미는?
  3. 모든 개발자는 사실 TDD를 하고 있다
  4. 알면서 왜 안할까? TDD
  5. TDD 안티 패턴
  6. 테스트되지 않은 코드는 쓰레기인가?
  7. 자동생성되는 메소드에 throw new UnsupportedOperationException() 넣기
  8. 유쾌한 이슈처리 재촉 메일
  9. 동상이몽 – TDD
  10. 스프링 컨테이너에는 설정파일이 없다
  11. Spring 3.0 (37) 스프링 모듈-라이브러리 의존관계 매트릭스 업데이트와 CTDD
  12. JUnitMax 개발/비즈니스 중단되다
  13. 코드리뷰와 인스펙션이 테스트보다 효과적이고 블랙박스 테스트가 단위테스트/개발자테스트보다 낫다고?
  14. 테스팅 프레임워크는 직접 만들어 써보자
  15. MockMultipartHttpServletRequest

Facebook comments:

to “TDD와 TLP”

  1. 안녕하세요. 잘 지내시죠?

    TLP는 켄트벡이 익스트림 프로그래밍 2판에서 TDD라는 이름 대신 Test First Programming이라는 이름을 쓰는 걸 보고(나중에 TDD란 이름을 다른 목적으로 쓰려고 했다고 합니다), 약간 변형을 해서 Test Last Programming이라고 지은 것인데, 그렇게 맘에 드는 이름은 아닙니다. 마치 개발 단계의 마지막에 이르러서야 테스트를 하는 나쁜 방식을 지칭하는 것 같아서 말이죠. 하지만, 되도록 테스트를 일찍, 자주 하는 것이 좋다는 것을 되새기게 하는 면에서는 긍정적인 부분도 있는 것 같네요.

  2. 김창준/ 안녕하세요. 친절하게 답도 직접 달아주시고 고마와요.
    TLP가 그거였군요. 라이선스 없으면 저도 좀 써먹을께요.

  3. 김창준님, 그런거라면 차라리
    Retrospective Test Programming (RTP) 이 낫지 않을까요?
    소급하는 테스트 프로그래밍

  4. 쓰고보니, 소급하는 테스트 프로그램을 짠다는 느낌이 나는거 같기도 하고,
    그럼 Programming and Test Retrospectively (PTR) 는 어떨까요?

  5. Kevin/ 전화번호 좀 다시 알려주세요. 번호가 다 날라가서.. ㅠㅠ

  6. TFD는 어떤가요? Test Following Development ^^;

  7. [Clean Code]읽다가 Cedric에 대한 밥삼촌의 답이 될만한 문구를 발견했습니다.
    “실제 코드를 구현한 다음에 테스트 코드를 만들면 실제 코드가 테스트하기가
    어렵다는 사실을 발견할지도 모른다. 어떤 실제코드는 테스트하기가 너무 어렵다고
    판명날지도 모른다. 테스트가 불가능하도록 실제 코드를 설계할지도 모른다”

  8. 구르마/ 테스트-라스트 방법을 사용하더라도 코드작성과 테스트 시간의 간격을 좁히면 충분히 testability가 높은 코드를 만드는데 도움이 된다고 봅니다.
    Cedric의 주장은 TDD보다 TLP가 무조건 낫다는 것이 아니라, TDD만이 유일한 단위 테스트(또는 개발자 테스트) 작성방법인 것처럼 이야기하지 말라는 것이죠.
    TDD가 가장 좋더라도 TDD는 당장 어려워서 못하겠다면, 짧은 테스트 주기를 가진 TLP가 낫고, 그나마도 힘들다면 일단 시간이 지난 뒤에라도 개발자가 단위 테스트를 만들어 보라고 설명해야 한다고 생각합니다.

    코드를 먼저 작성하더라도 테스트를 의식하면서 할 수 있습니다. 테스트하기 좋은 코드는 사실 TDD 때문에 만들어진다기 보다는 유연한 설계 덕분에 만들어진다고 생각합니다. 물론 TDD가 좋은 가이드가 되주긴 하겠죠. Clean Code의 문구는 맞는 말이지만 너무 막연하네요. 테스트는 코드를 작성하고 나중에 여유가 있을 때 만들어도 마찬가지 아니냐는 핑계를 대거나, 테스트편의성을 전혀 고려하지 않고 유연성이 떨어지는 코드를 생각없이 개발하는 개발자들에게 해줄 수 있는 조언 정도인 것 같습니다.

  9. TDD가 단순히 testability만을 높이는 효과만 있지는 않다고 생각합니다만. 다른 주요 효과로는 Ron Jeffries가 말한 TFD(Test First Design)가 아닐까합니다. [테스트 먼저]라는 행위가 프로그래머로 하여금 구현보다는 인터페이스의 관점을 강제하고, 또한 테스트가능성을 높이기 위한 부하가 다른 요소와의 분리를 강제하고, 이것이 자연스럽게 좋은 디자인으로 이끌어 준다는 점이지요.

    저도 테스트-라스트 방식을 종종 애용(?)하기도 합니다만, 특히 레거시 코드에서는…, 왠지 약간 염려되는 것은
    김창준님이 분석하신 TLP > TDD라는 기여도 분석이 자칫 TLP > TDD라는 효과적 우수성(현실성에 기반한)이라는 것으로 해석되어지는 것이 아닌가 하는 점입니다.

    이 블로그 첨인데, 재미있는 글들이 참 많네요. 배울 것도 많구요. 종종 들려보겠습니다.

  10. 구르마/ 제가 testability 얘기를 꺼낸 것은 구르마님이 인용하신 Clean Code의 내용이 테스트를 나중에 만들면 테스트 하기 어려운, 즉 testability가 낮은 코드가 나오게 된다는 주장인듯 해서 꼭 그렇지만은 않다고 얘기한 것 뿐입니다.
    저는 TLP가 TDD보다 더 낫다고 오해하는 한이 있더라도 일단 TLP라도 시작하는 것이 바람직하다고 생각합니다. 당장에는 자동화된 개발자 테스트의 유용성을 몸으로 느껴야 하고, 그리고 서서히 TLP를 통해서 코딩과 테스트 간격을 좁혀나가고, 테스트를 의식하면서 코드가 만들어지는 수준까지 올라가야 할 것이고, 궁극적으로 코딩과 테스트의 간격이 마이너스가 되는 TDD로 발전하는 것이 자연스러운 것이 아닌가 생각합니다.

    코딩 후 테스트 만드는 것도 받아들이기 힘든 개발자들에게 처음부터 TDD의 장점만을 강조하면서 바로 TDD를 시작하라고 강요하는 것은 폭력적이라고 생각합니다. 충분한 수련의 기회와 시간을 제공한다면 모르겠지만요.

  11. tramadol online tramadol dosage chart – tramadol generic

  12. Hello! dkfagfc interesting dkfagfc site! I’m really like it! Very, very dkfagfc good!

  13. Hello! ddkddge interesting ddkddge site! I’m really like it! Very, very ddkddge good!

  14. … [Trackback]…

    [...] Informations on that Topic: toby.epril.com/?p=1030 [...]…

  15. Great piece of information! May I reference part of this on my blog if I post a backlink to this webpage? Thanks.

  16. mbt shoes mens TDD와 TLP » Toby’s Epril

  17. mbt tariki shoes TDD와 TLP » Toby’s Epril

  18. I’m pretty pleased to uuncover this page. I wanted to thank you for your tim
    due to this wonderful read!! I definitely really
    liked every part of it and i also havve you book marked to look at new stuff in your site.

Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha