실용주의이야기(Pragmatic Story)

얼마전 XP를 만든 켄트벡이 자신의 사이트에 다음과 같은 제목의 글을 하나 올렸습니다.

TDD is Kanban for Code

내용이 그리 길지 않고 어렵지 않으니 읽어보세요. TDD에  대한 이해를 좀 더 깊게 해줍니다. 주요 내용을 간단히 맵으로 정리했습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Steve Freeman과 Rebecca Wirfs-Brock은 운좋게도 개인적으로 몇 번씩 만나본 분들입니다.(뭐 그렇다고 그분들이 절 기억하지는 못하겠죠. ^^) 오늘 블로깅 하다 재밌는 글을 하나 발견해서 링크합니다.

Mocks are not about isolation, but about responsibilities

단위테스트를 만들때 DB나 File과 같은 IO와 엮이게 되면 여러가지 문제가 뒤따릅니다. 그래서 이런 이슈를 해소하기 위해 Mock객체를 만들어서 테스트코드와 환경을 분리(isolation)하게 됩니다.

지난주 유럽 CITCON에서 Freeman은 목 객체에 대한 생각을 레베카의 Roles, Responsibilities and Collaborations object design school에서 영감을 얻었다고 발표했습니다. 그는 Mock객체를 단순히 분리를 위해서 사용하지 말고 디자인을 위해서 사용하라고 충고합니다.

인터페이스는 호출할 메소드만을 나타내기 때문에 객체를 명세하는데 충분하지 않다. 언제 어떻게 호출하는지는 알려주지 않는다. 그래서 목 객체가 필요한 것이다.

목객체를 만드는 나쁜 경우는 표준 자바 라이브러리를 목으로 만드는 경우라고 합니다. 더 자세한건 링크를 참고하세요.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

ZD Net, 분석, 설계 기법으로서의 테스트 주도 개발, 이종국

이런 제목의 글이 ZD Net에 실리는것을 보니 우리나라에도 애자일이 많이 확대되고 있는거 같아서 기분은 좋네요. 그런데 글 내용은 그냥 그런거 같습니다. 제가 그렇게 생각하는데는 몇가지 이유가 있는데요..

• 너무 어렵게 설명하고 있습니다.: 관련내용을 잘 알고 있다고 생각했는데 무슨 말을 하는지 이해하느라 몇 번 읽어봐야 했습니다. 나름 이해를 잘한다고 생각하고 있는데..^^
• 영어를 번역해 놓은것 같은 문장이 많습니다.: 글이 잘 익히지 않는게 마치 번역을 해 놓은듯한 느낌이네요.
• 내용상에 몇가지 오해의 소지가 있습니다.: TDD를 하면 시스템을 전부 재개발해야 하는 것처럼 설명한 부분, TDD를 하면 더 이상의 테스트가 필요없다 식의 논리는 비 현실적이라 생각됩니다.

요즘들어 글쓰기가 어렵다는걸 부쩍 느끼고 있습니다. ZD Net과 같은 기사는 더 엄히 확힌해야 하지 않을까요.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

다음은 Method & Tools에서 이번 하반기에 Unit Test에 대해 조사한 설문 결과입니다.


2006년도에 비하면 Unit test case를 문서로 만들거나 하는 일은 더 줄어 들었고, TDD에 대한 선호도는 약간 커진걸 알 수 있습니다.

이 자료보다 2007년 하반기에 TDD에 대한 조사가 더 재밌습니다.


결과를 종합해 보면 TDD가 코드에 에러를 잡는데 매우 효과적이지만 약 16%정도만이 실제로 이를 활용하고 있다고 응답했습니다. 활용하는 이유는 회귀테스트, 유지보수성, 개발시간 단축등을 들고 있네요.

유사한 조사 결과가 2008년 3분기 Geospatial Developer Survey에 나와 있습니다.


우리의 현실과 크게 다르지 않아서 안심 했습니다. ^^ 왜 사용하지 않는 걸까요 ?


이것도 우리와 비슷하네요. 프로젝트에서 이를 쓸 시간이 없다가 40%에 가깝군요. 너무 어렵다는 응답도 20% 정도 됩니다.

사실 이런 조사가 TDD나 Unit Testing에 대한 모든것을 대표하지는 못합니다. 하지만 TDD를 적용하기 위해서 우리가 어떤 부분을 준비해야 하는지 엿볼 수 있어서 좋은거 같습니다.

TDD는 어렵습니다. 한번에 사용하는것도 쉽지 않습니다. 프로젝트에서 TDD로 한번에 가기 보다는 단계를 거치는게 좋을거 같습니다.

• 개발하고나서 테스트 코드를 만든다.(Test Automation)
  
• 테스트를 어떻게 할지 먼저 생각해보고 코드를 작성한다.(TFD)
• 테스트를 먼저 작성하고 코드를 작성한다.(TDD)
  

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.