TDD 배워야 할까?
seeyoung
가 있냐는 반문도 너무 반가웠습니다. 함께 의견을 나누면 좋겠다는 생각에서요.
답글 형태로 해도 되겠지만, TDD에 대해 따로 진행되는 좋겠다는 바람에 새게시물로 포스팅합니다.
일단, 제 경험을 얘기드리지요. 단위테스트를 어떻하면 잘 해볼 수 있을까 고민하다가 TDD의 텍스트랄수 있는 Test-
Driven Development: By Example 번역서인 테스트 주도 개발이라는 책을 뒤늦게 읽고 있습니다.
Unit Test를 제대로 하고 싶은데, 그게 쉽지 않더군요. 나름 작성해 봤지만, 일단 시작하기도 만만치 않고, 지속하기란
더 힘들더라구요. 하여, 좋은 방법이 없을까 궁리끝에 JUnit을 만든 켄트 벡 선상님의 책을 읽어보면 좋은 실마리가 있겠다 싶
었지요.
제 생각은 적중한것 같습니다. 틈틈히 읽느라 아직 반에 반도 못 읽었지만, 예제를 통해 설명하는 TDD와 단위테스트의 묘미 그리
고, 그를 통한 보다 깔끔한 코드가 만들어지는 모습에서 감탄이 나오더군요. 물론, 따라한다고 다 되는것 아니겠지만, 그 예제를
따라하면서 수련을 잘 하면 나도 비스무리하게 할 수 있을것 같다는 용기를 주고 있습니다.
전 TDD를 통해 단위테스트를 수련해보는것이 단위테스트를 배우는데 굉장히 도움을 줄 수 있다는 생각입니다. 실제 개발을 TDD
로 하느냐를 떠나서요.
TDD로 개발한 경험이 있는 분의 경험담을 듣고 싶네요. 기타 단위테스트와 TDD에 대한 다양한 의견이 줄줄이 매달리길 기대해봅
니다.
Sanghyuk Jung
--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.
박성철
개인적으로 책을 산 건 좀 되었지만 진지하게 대한 건 한 2년 된 것 같네요. 당시에는 대형 SI 프로젝트에 참여하고 있었기 때문에 팀 차원의 본격적인 TDD나 짝프로그래밍을 하지는 못했고 그냥 개인적으로만 수행했습니다.
그러다 봄싹 스터디에서 짝프로그래밍과 TDD 스터디를 하면서 본격적으로 실무에 활용하게 된 것 같습니다. (그런데 실무에서 코딩할 일이 점점 줄어드는 게 문제이긴 합니다. -_-);
TDD는 무엇인가?
제가 작년 초 지금 있는 회사에 처음 들어왔을 때, 얼마전 TDD 세미나를 했다고 하더군요. 그래서 세미나 발표 자료를 봤더니 대부분 내용이 junit test case 작성법이었습니다. 단위 테스트를 하는 게 TDD라고 생각한 것이죠. 이렇게 오해하는 사람을 많이 만나봅니다.
그리고 단순히 테스트를 먼저 만드는게 TDD라고 생각하는 사람도 있습니다. TDD가 아니라고 잘라서 말하기는 그렇지만 TDD가 목적을 살리지는 못한다고 봐야할 듯 합니다. (이런 것에 굳이 이름을 붙인다면 책에 나온 Test First Developmet라고 말할 수 있을 듯 합니다. TFD는 TDD까지 포함하는 큰 개념 같지만요.)
TDDBE에서 켄트백은 이렇게 말합니다.
TDD is an awareness of the gap between decision and feedback during programming, and techniques to control that gap.번역판을 가지고 있지 않아 그냥 제가 번역해보면 "어떤 결정을 하고 그 결정이 옳은지 알 수 있는 피드백을 얻는 간격을 프로그래밍하는 중에 의식하면서 이 간격을 조절하는 기술" 정도가 될 것 같은데요. 결국 내가 옳바로 진행하고 있다는 용기를 계속 확인하면서 진행하는 기술이 TDD라고 생각합니다.
실무에 TDD를 쓰는가?
이런 질문을 누군가 저에게 하면 일단 쓴다고 말합니다. 그런데 100% 모든 코드를 TDD로 작성하지는 않는다고 덧 붙입니다.
그냥 TDD하기 좋은 코드에 TDD를 씁니다. 테스트 케이스를 만들기 쉬운 경우는 대부분 TDD를 하는 편이고요. 특히 전 공통 모듈 쪽 작업을 하는 일이 많으니 먼저 테스트 케이스로 정상적으로 작동하는지 확인해봐야 할 일이 많고 당연히 이럴 때는 TDD로 코딩을 합니다.
TDD 변형
문제는 SI 프로젝트에서 누가 자동화된 테스트 케이스를 작성하라고 요구하지도 않고 구현할 요구사항이 너무나 단순한 반면 개발해야 할 양이 많을 때, 그리고 그 코드를 제가 유지보수할 일이 없을 때에도 TDD를 하느냐는 것이겠죠.
일단 테스트 케이스를 만들지는 않습니다. 하지만 나름 TDD를 변형해서 충분하지는 않지만 유용한 피드백을 받을 수 있는 방법을 찾습니다. 전 이걸 혼자 Client Driven Development라고 하는데요. 어떤 객체 만들 때 그 객체를 소비하는 client 객체와 동시에 번갈아가며 개발하는 거죠. 일반적인 Controller-Service-Dao 구조라면, Service를 만들 때는 Controller와 함께, Dao를 만들 때는 Service와 함께 번갈아가면 개발을 합니다.
핵심은 적당한 주기로 작은 결정을 반복하면서 진행해 나가는 개발 방법이 TDD이니 테스트 케이스를 만드는 게 확실한 부담일 때는 이렇게라도 하면 도움이 되움이 되더군요.
Greenxk
코드의 생산성과 간결성이 보장된다는 점이 있겠죠..
하지만, 이것만 가지고 TDD를 쓴다면, 굳이 필요는 없겠죠..
TDD의 숨어있는 기능중에 회귀테스트가 있습니다.
대 단위 소프트웨어 시스템을 구축하게 될때, 어느 곳에서 오류가 터졌다고 할때,
그것을 즉각적으로 알아내어 수정할 수 있는 경우는 얼마 안됩니다.
컴파일시 코드오류를 제외하면, 논리적 오류와 유효성 오류 등은 좀처럼 찾아내기가 쉽지가 않죠..
솔직히 개발시 가장 시간을 많이 잡아 먹는 부분이, 코딩보다 검증과 오류를 찾아 내는데 있습니다.
또 오류를 곧바로 알아낸다해도 수정하고 작동이 되는지 검증 하는 과정을 반복 하다 보면..
생산성은 자연히 떨어지게 되어 있습니다.
그런면에서 TDD에 의한 TestCase를 잘 구축해 놓으면, 빌드시 곧바로 논리적 오류를 비롯한 각종 오류를
쉽게 알아 낼수가 있습니다.
이를 회귀 테스트라고 하죠. 말그대로 현재 까지 구축한 시스템을 수정한후 모든 기능을 처음부터 끝까지 다시 테스트 한다는 의미
인데
TestCase가 잘 구축되어 있다면, 이는 컴퓨터가 알아서 테스트 하고 오류난 곳을 자동으로 알아내어
프로그래머에게 알려줍니다.
이러한 회귀 테스트가 잘 구축이 된다면, 에자일에서 말하는 기민한 개발이 가능해 지고, 소프트웨어의 완성도도 높아지지요.
그리고, 지속적인 통합이 가능하여, 어떤 시스템과도 잘 물릴수가 있고, 소프트웨어의 규모가 커지더라도 통제가 얼마든지 가능합니
다.
또, TestCase 자체가 이 소프트웨어의 이력과 역사가 되어, 주석문 이상의 메세지를 사용자에게 전달 할 수도 있습니다.
머 여기까지가.. 제가 읽은 책들에서 발췌한 내용들을 정리한 내용입니다..ㅡ_ㅡ;;
사실, 현업에서 TDD를 쓴다는 건 전체 개발자와의 협의 과정이 필요한 관계로, 자칫 이단으로 몰릴 수가 있어 쓰지는 못하지
만..
중요한 몇몇 부분 만이라도 개인적으로 구축해보고는 합니다..
그리고, 개인적으로 블로그를 하나 만들고 있는데, TestCase를 무조건 작성해서 만들고 있습니다..
첨엔 좀 숙달하느라 힘들고, 이리 저리 배보다 배꼽이 더 크다는 느낌도 들고 그랬는데..
어느 정도 진척이 되면서, 이거 참 물건이네라는 생각이 들고 있어요..
무언가 코드를 고치고 나서, 이거 과연 잘 작동 될까? 라는 의문이 들때...
TDD가 알아서 검증을 해주니... 이것 만큼 고마울때가 없는 것 같습니다...
켄트 벡의 테스트 주도 개발론 꼭 읽어 보시고, 곁들여 마틴파울러의 '리팩토링'을 읽어 보시면 많이 도움이 됩니다...
Jisung, Ahn
Test case 들이 변화에 대한 저항으로 작용할수 있습니다.
열심히 테스트를 작성하다가 어느날 머리속에서 번쩍한 멋진 아이디어를 반영하려고 했는데 기존 코드 고치는것도 시간이 걸리는데 테스트케이스 까지 고치는 것은 아주 어려운 일이 되어버립니다.
이걸 고쳐 말아, 하다가 테스트 케이스를 포기하던가 아이디어를 포기하게 되는 경우가 종종 발생합니다.
제 경험상 이게 가장 큰 단점이였습니다.
그런데 이런 사소한 단점을 제외하면 TDD는 배우면 좋은 겁니다. 그건 장담할수 있어요.
2010. 1. 26., 오후 6:32, seeyoung 작성:
Jin Kim
지성님 말씀처럼 그런 부분이 제일 큰 장점이죠..
그런데, TDD 책을 보면, 항상 메모를 하면서 TDD를 작성 하라고 분명하게 나와 있습니다.
아이디어가 떠올랐을때.. 메모를 해두고 하는 습관은 필수더라구요.. 도움도 되고..
그렇지만...역시 지연된다는 단점은...
대신.. 이런건 있습니다.
처음에 생성된 코드는 당연히 변화를 장담할 수가 없습니다. 이거 추가 하고 저거 추가 하다보면
TDD가 너무 발목을 잡는다는 느낌은 들죠..
그런데, 어느 선을 넘어 안정된 코드가 되었을 땐, 굳이 그 코드를 고치지 않아도 되는 신기한 현상도 경험하게 되더라구요...ㅡ
_ㅡ;;
저만 그런가?
아, 그리고, 리팩토링은 필수더라구요.. 실 프로그램 자체를 리팩토링도 하지 않은체..
클래스 크기만 비대하게 키워 놓고.. 클래스 자체가 제 기능을 못한 상태에서..
TestCase 만드니깐.. 안한만 못한 결과가 나오고 그렇더라구요..
TDD를 하기 위해서는.. TestCase 말고도.. 결과물 자체에도 신경을 많이 써주고.. 적절한 리팩토링과, 객체 지향에 의
한 패턴 적용도 필수더라구요..
머랄까... TDD를 제대로 쓰기 위해서는 공부도 제대로 해야 된다랄까...
백기선
--
좋은 하루 되세요~
One Bread
따라서 TDD를 배워야 할까라는 말을 그냥 TDD의 전제조건인 테스트코드(단위, 자동화 테스트)를 만든다는 것을 포함시켜서 생각할 수도 있지만, 저는 그걸 제외하고 단위테스트 작성 방법에서 테스트를 먼저 만들어 일종의 설계, 가이드, 검증 용으로 사용하는 방법으로서 TDD를 배워야 할까에 대해서 생각해보는 것이 필요할 것 같아요.
왜 스프링 개발자들은 TDD를 적용하지 않았을까요? 물론 테스트를 많이 만들었다는 것은 알고 있지만 TDD가 아니라, 먼저 설계하고 코드도 만든 뒤에 일부 기능을 검증하기 위해서 만들었다고 들었어요. TDD가 그렇게 좋다면 왜 스프링개발자들은 사용하지 않을까요? DB나 웹 같이 테스트 하기 힘든 서버 프로그램도 아니고 프레임워크인데도 말이에요. 그게 궁금해요.
단위테스트나 회귀테스트 같은 이미 누구나다 인정하는 테스트코드 작성에 대한 것 말고, 순수하게 TDD가 왜 중요하고 그것을 배우는 것이 테스트를 코드 작성한 후에 만드는 것보다 어떤 면에서 장점이 있을까에 대해서 얘기해주실 분은 없나요? 또는 앞에서 어느 분이 하신 말씀처럼 "TDD하기에 적당한 스타일의 프로젝트"가 따로 있는 것일까요? 스프링 프로젝트는 과연 테스트코드 작성이나 목 오브젝트 사용, 회귀테스트 작성을 넘어서 TDD까지 적용하기에 적합할까요?
ilovemedic
테스트 주도 개발을 읽으면서 먼저 드는 생각은 "그래서 뭐 어쩌라고?" 였습니다,
그 책의 예제에서 나오는 당연한 코드를 왜 그리 어렵게 짜냐 라는 생각이 드는 것은 저 뿐 만이 아니였군요.
>>테스트를 코드 작성한 후에 만드는 것보다 어떤 면에서 장점이 있을까에 대해서 얘기해주실 분은 없나요?
어줍잖은 저의 소견으로는 눈이 휘둥그레질만한 장점은 없는것 같습니다.
복잡한 도메인 로직을 쪼개고 (문제를 지역화한다라고 말하더군요)
쪼갠 단위로 차근차근 해결해 나가는 방법중에 Test First 가 아주 멋진 방법이라고 생각합니다.
복잡한 도메인 로직을 미래의 나 자신 혹은 누군가에게 설명하기위해 이것보다 좋은 것은 없어 보입니다,
그런데 이러한 과정을 기록 (별도의 클래스로 저장) 하지 않는 이상 이걸 설명하기가 어렵지 않느냐 라는 생각도 듭니다.
차라리 그것 보다는 단위테스트 또는 자동화 테스트를 통해 테스트 커버리지를 올리는 것이
Test First 보다 더 중요한것이 아닐까요?
>>스프링 MVC를 적용하신 프로젝트에서 핸들러 맵핑, 뷰 리졸빙, 핸들러 어댑터, 바인딩, 검증, 서비스 계층 이하를 다녀오는 부분과
>>세션에 들어있는 객체 스코프 등등을 TDD로 작성하시는 분 계신가요?
>>이런 것들은 스프링이 제공하는 기반 시설이니까 스프링에서 알아서 해줄꺼다. 라고 무마하기엔 현재 너무 다양한 용법과 활용방안으로
>>테스트없이는 예측하기가 불안합니다. 이런 상태에서 위의 것들을 효율적으로 TDD하고 계신분 있으신가요?
말 그대로 "스프링이 제공하는 기반 시설" 에 대한 테스트를 왜 하는지 의구심이 듭니다,
프로젝트를 진행하면서 테스트가 정말로 필요한것은 그 프로젝트의 도메인 로직 부분이라고 생각됩니다.
도메인 로직을 개발할때 TDD의 절차(Test First)를 따르던 울트라 캡숑의 지혜를 발휘하던간에
프로젝트의 최종 결과는 TestCase 작성으로 클래스의 정상 작동을 검증하는 면을 더 중요하지 않겠습니까?
On 1월27일, 오전7시53분, One Bread <onebread....@gmail.com> wrote:
> 글을 읽어보니 TDD와 단위테스트 또는 자동화 테스트의 장점이 그냥 뭉뚱그려져서 나오는 것 같같네요. 단위테스트 코드를 만들어
> 회귀테스트가 가능한 자동화 테스트를 구축한다고 하더라도 TDD가 아닐 수 있다고 알고 있어요. TDD는 단순히 테스트 먼저-코드 나중
> 만으로 되는 것은 아니지만 테스트를 항상 먼저 만드는 것은 은 켄트 벡 책의 가장 처음에 나오는 TDD 방법 설명에 나오는 것처럼 기본
> 원칙인 것 같아요. 실패한 테스트를 성공시키기 위한 목적 외에는 코드를 작성하지 말라는 말도 나오네요.
>
> 따라서 TDD를 배워야 할까라는 말을 그냥 TDD의 전제조건인 테스트코드(단위, 자동화 테스트)를 만든다는 것을 포함시켜서 생각할 수도
> 있지만, 저는 그걸 제외하고 단위테스트 작성 방법에서 테스트를 먼저 만들어 일종의 설계, 가이드, 검증 용으로 사용하는 방법으로서
> TDD를 배워야 할까에 대해서 생각해보는 것이 필요할 것 같아요.
>
> 왜 스프링 개발자들은 TDD를 적용하지 않았을까요? 물론 테스트를 많이 만들었다는 것은 알고 있지만 TDD가 아니라, 먼저 설계하고
> 코드도 만든 뒤에 일부 기능을 검증하기 위해서 만들었다고 들었어요. TDD가 그렇게 좋다면 왜 스프링개발자들은 사용하지 않을까요? DB나
> 웹 같이 테스트 하기 힘든 서버 프로그램도 아니고 프레임워크인데도 말이에요. 그게 궁금해요.
>
> 단위테스트나 회귀테스트 같은 이미 누구나다 인정하는 테스트코드 작성에 대한 것 말고, 순수하게 TDD가 왜 중요하고 그것을 배우는 것이
> 테스트를 코드 작성한 후에 만드는 것보다 어떤 면에서 장점이 있을까에 대해서 얘기해주실 분은 없나요? 또는 앞에서 어느 분이 하신
> 말씀처럼 "TDD하기에 적당한 스타일의 프로젝트"가 따로 있는 것일까요? 스프링 프로젝트는 과연 테스트코드 작성이나 목 오브젝트 사용,
> 회귀테스트 작성을 넘어서 TDD까지 적용하기에 적합할까요?
>
> 2010/1/27 백기선 <whiteship2...@gmail.com>
>
>
>
> > 제가 보기엔 다들 피상적이시네요. 이런 이야기들 보다는 실제 프로젝트에서 어떤 부분을 어떻게 TDD로 작성하셨는지 알려주시면 도움이 될
> > 것 같습니다.
>
> > 스프링 MVC를 적용하신 프로젝트에서 핸들러 맵핑, 뷰 리졸빙, 핸들러 어댑터, 바인딩, 검증, 서비스 계층 이하를 다녀오는 부분과
> > 세션에 들어있는 객체 스코프 등등을 TDD로 작성하시는 분 계신가요?
>
> > 이런 것들은 스프링이 제공하는 기반 시설이니까 스프링에서 알아서 해줄꺼다. 라고 무마하기엔 현재 너무 다양한 용법과 활용방안으로
> > 테스트없이는 예측하기가 불안합니다. 이런 상태에서 위의 것들을 효율적으로 TDD하고 계신분 있으신가요?
>
> > 있다면 어떻게 하고 계신지, 안하고 계시다면 왜 안하고 있는지. 그런 이야기가 실용적이고 도움이 되지 않을까요?
>
> > 2010년 1월 26일 오후 8:59, Jin Kim <eigenb...@gmail.com>님의 말:
>
> > 구현할 것과 구현 방식 등이 잘 정의되어 있다면 TDD가 좋을 수도 있겠습니다만,
>
> >> 어떤 새로운 아이디어를 실험해 가면서 구현을 정리해 나가던가 아니면 새로운 라이브러리, API 등을 조사해 가면서 구현해 가는 경우
> >> TDD는 별로 좋은 선택이 아닌 거 같습니다.
> >> 이런 경우 구현을 먼저 하고 Test를 이용해 디버깅을 하는 TDD(Test Driven Debugging)이 좋겠지요 :)
>
> >> 이런 경우 Test도 보통 한번 쓰고 버리는 거라서 회귀 테스트의 의미도 별로 없는 듯 하구요.
>
> >> TDD 스타일로 개발하려고 몇번이나 시도해봤지만 힘들기만 하고 별 효과가 없어서 그 이유를 고민해 보니 TDD에 프로젝트의 스타일이
> >> 있는 게 아닌가하는 생각이 드는군요.
>
> >> 2010년 1월 26일 오후 8:29, Greenxk <gree...@gmail.com>님의 말:
>
> >> 지성님 말씀처럼 그런 부분이 제일 큰 장점이죠..
>
> >>> 그런데, TDD 책을 보면, 항상 메모를 하면서 TDD를 작성 하라고 분명하게 나와 있습니다.
>
> >>> 아이디어가 떠올랐을때.. 메모를 해두고 하는 습관은 필수더라구요.. 도움도 되고..
>
> >>> 그렇지만...역시 지연된다는 단점은...
>
> >>> 대신.. 이런건 있습니다.
>
> >>> 처음에 생성된 코드는 당연히 변화를 장담할 수가 없습니다. 이거 추가 하고 저거 추가 하다보면
> >>> TDD가 너무 발목을 잡는다는 느낌은 들죠..
> >>> 그런데, 어느 선을 넘어 안정된 코드가 되었을 땐, 굳이 그 코드를 고치지 않아도 되는 신기한 현상도 경험하게 되더라구요...ㅡ
> >>> _ㅡ;;
> >>> 저만 그런가?
>
> >>> 아, 그리고, 리팩토링은 필수더라구요.. 실 프로그램 자체를 리팩토링도 하지 않은체..
> >>> 클래스 크기만 비대하게 키워 놓고.. 클래스 자체가 제 기능을 못한 상태에서..
> >>> TestCase 만드니깐.. 안한만 못한 결과가 나오고 그렇더라구요..
>
> >>> TDD를 하기 위해서는.. TestCase 말고도.. 결과물 자체에도 신경을 많이 써주고.. 적절한 리팩토링과, 객체 지향에 의
> >>> 한 패턴 적용도 필수더라구요..
>
> >>> 머랄까... TDD를 제대로 쓰기 위해서는 공부도 제대로 해야 된다랄까...
>
> >>> --
> >>> Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
> >>> 이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
> >>> 그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com<ksug%2Bunsu...@googlegroups.com>로
> >>> 이메일을 보내주세요.
> >>> 더 많은 옵션을 보려면http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.
>
> >> --
> >> Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
> >> 이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
> >> 그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com<ksug%2Bunsu...@googlegroups.com>로
> >> 이메일을 보내주세요.
> >> 더 많은 옵션을 보려면http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.
>
> > --
> > 좋은 하루 되세요~
>
> > --
> > Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
> > 이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
> > 그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com<ksug%2Bunsu...@googlegroups.com>로
> > 이메일을 보내주세요.
> > 더 많은 옵션을 보려면http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.- 원본 텍스트 숨기기 -
>
> - 원본 텍스트 보기 -
백기선
프로젝트를 진행하면서 테스트가 정말로 필요한것은 그 프로젝트의 도메인 로직 부분이라고 생각됩니다.
'기반 시설'이라는 용어가 다소 애매했던 것 같은데요. 스프링의 라이브러리가 아니라 그걸 조합해 놓은 애플리케이션의 기반 시설이라고 하면 조금 제가 뜻하는 것과 비슷할지 몰겠습니다.
애플리케이션의 아키텍처에 지대한 영향을 끼치게 그런 설정 내지 클래스들은 하다못해 인터셉터라도 하나 잘못 추가하는 날에는 불필요한 오버헤드가 발생하거나 엉뚱하나 곳에 인터셉터가 물릴 수도 있을텐데 그런 것은 TDD로 하지 않으면서 도메인 로직만 TDD를 한다는건 일관성이 없습니다.
따라서 분명히 해야하고, 하고 싶은대도, 잘 안하게 되는.. 어떤 이유가 있을거라고 생각이 됩니다. 그게 무엇인지 같이 고민하고 그 해결책을 모색하고 싶네요.
그 중 하나가 request스코프 같은 녀석인데.. 얼마전 Toby님 블로그에 관련 글이 올라와서 상당히 충격을 받았었습니다.
http://toby.epril.com/?p=972
위와 같은 테스트가 의미없는 테스트라고 생각하지는 않습니다. 이와 비슷한 것으로 AOP 포인트컷 테스트도 있지요.
도메인 로직을 개발할때 TDD의 절차(Test First)를 따르던 울트라 캡숑의 지혜를 발휘하던간에
프로젝트의 최종 결과는 TestCase 작성으로 클래스의 정상 작동을 검증하는 면을 더 중요하지 않겠습니까?
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.
--
좋은 하루 되세요~
박성철
다 흥미로운 주제들입니다만 Xper에서라면 더 활발하게 답변이 달렸을 것 같
다는 생각도 드네요.
물론 그 쪽은 너무 전문가들이라서 일반인의 어려움을 몰라주는 경우도 많지
만요. ㅎㅎ
> Test case 들이 변화에 대한 저항으로 작용할수 있습니다.
>
이건 TDD의 단점이라기 보다는 테스트 자동화의 단점(물론 진짜 단점인지는
따로 생각해 볼 문제이겠지만 일단 유지보수할 코드가 더 있으므로 단점이라
고 해보죠)이라고 봐야할 듯 합니다.
> 열심히 테스트를 작성하다가 어느날 머리속에서 번쩍한 멋진 아이디어를 반영하려고 했는데 기존 코드 고치는것도 시간이 걸리는데 테스트케이스 까지 고치는 것은 아주 어려운 일이 되어버립니다.
>
TDDBE에서 켄트 백이 반복적으로 강조하는 게 "어떻게 코딩할까?" 보다 "어떻
게 테스트할까?"를 먼저 생각하라는 거죠. 수정할 때도 마찮가지라고 생각합
니다. 새로운 아이디어를 반영할 때 역시 TDD 방식이라면 "어떻게 테스트할
까?"를 먼저 생각하게 되고 자연스러운 개발의 일환으로 테스트 케이스와 코
드를 함께 수정해나갈 것입니다.
리펙토링 기법까지 적용한다면 끊임없이 코드가 작동 상태라는 것을 확인해야
하니 테스트 케이스와 코드를 동시에 개선하는 건 더욱 필수적이겠죠?
만약 TDD를 안 하고 테스트 자동화를 한다면 본 코드를 수정하는 작업 외에
또 다른 작업이 더해지는 심리적인 부담을 느끼겠지만 TDD에서라면 자연스럽
게 한 작업 내에서 테스트 케이스와 코드가 동시에 개선되므로 부담이 덜해진
다고 봅니다. 더우기 개선 과정에서도 짧은 단계로 코드가 정상적으로 작동한
다는 것을 확인하기 때문에 더욱 안심하고 수정할 수 있겠고요.
사실 TDD는 물론이고 테스트 자동화 자체가 처음에 개발할 때 보다는 이렇게
코드를 개선해나갈 때 오히려 더 유용한 개발 도구라고 생각합니다. 그러니 "
테스트 코드까지 유지보수 하려니 귀찮군" 보다는 "테스트 코드 덕분에 안심
하고 수정할 수 있겠어"에 더 가치를 부여하고 싶네요.
물론 이건 복잡한 코드일수록 더 의미있기에 단순하고 빤하게 예측할 수 있는
코드라면 귀찮다는 쪽에 더 무게가 실릴 겁니다. TDD나 테스트 자동화가 항상
유용한 건 아니니까요.
윤성한
'어떤 한 철학적인 질문에 대해서 답을 발견할 수 없어요. 답이 있는 문제 같으면 아직까지 질문이 남아있을 리가 없거든요. 우리가 품는 대부분의 문제들은 수천 년 동안 사람들이 질문을 던졌지만, 말끔하게 논리적으로 해결되지 않은 게 대부분이에요. 이런 질문들은 각자가 평생을 끌고 가는 거거든요. 한 시기에 답을 발견했다 할지라도, 시간이 좀 지나고 나면, 다른 답을 발견할 수도 있고요. 그럼 다시 물음표로 가는 거고요. 사람 사는 게 그런 거 같아요. 답이 없어요. 이 책에도 나름 발견했다는 답도, 한 20년 지나서 다시 읽어보면, ‘왜 이렇게 썼을까?’ 하는 것들이 생기겠죠.'
박성철
그래서 이런 토론이 의미 있다고 봅니다. 정답이 없기 때문에 (또는 아직 찾
지 못했기 때문에) 다양한 경험과 생각을 나누면서 유용한 뭔가를 함께 찾고
공유하는 과정 말이죠.
켄트 백도 같은 생각을 하는 것 같습니다. TDDBE에서도 자기가 XP와는 다르게
TDD는 "반드시 이러이러해야한다"고 말하지 않고 좀 조심스럽다고 얘기합니
다. 열광적인 TDD 지지자들이 발전시킨 TDD의 급진적인 아이디어에 대해서도
"잘 모르겠다"는 식으로 한 걸음 뒤로 빠지곤 하죠. 아직 더 많은 경험이 축
적되어야 한다고 생각하는 것 같습니다.
> 개인에 따라 개발방법 또는 습관이 다를테고, 환경, 경험, 지식 정도에 따
> 라 원하는 또는 필요한 수준의 소스 품질이 다를텐데, 어떤 기준으로 무엇
> 에 대한 지지벡터 점를 잡는다는것은 어렵겠단 생각이 들어요. 마치 철학처
> 럼요. 그래서 옳고 그름, 표준과 비표준 보다는 자신의 환경에 맞는것을
디키
TDD는 기술적인 부분 보다는 심리학적 부분이 크다고 생각합니다.
첫째 요구사항의 이해입니다. 일단 코드부터 짜는 많은 개발자들에게 진정 요구사항을 이해했는지 코드로 작성해보라는
의도가 엿보입니다.
둘째. 테스트 되지 않은 코드의 출시를 막는 것입니다. 요즘처럼 기한내 출시만을 목표로 할 때 누락 하기 쉬운 것이 테스트 입니
다.
자신의 코드를 테스트 하지 않고(혹은 못하고) 커밋하는 개발자들에게 극단적으로 테스트를 먼저 작성하게 함으로써
의무화 시키는 것입니다.
정말... 무서운 켄트 벡입니다. TDD로 자아반성을 할 거리를 던져주다니...
> > 유시민님의 인터뷰글로 위로 삼습니다. ^^;;;- 원본 텍스트 숨기기 -