독자리뷰
계륵(鷄肋) 같은 테스트 주도 개발
shado***
2010-07-09
테스트 주도 개발 : 고품질 쾌속개발을 위한 TDD 실천법과 도구
개발자들 사이에서 끊임없이 회자되는 애자일(Agile), 그런 애자일을 둘러싼 많은 기법 중에 테스트 주도 개발은 단연 손꼽히는 기법이다. 그러나 막상 참고할 만한 국내 서적이 없기 때문에 원서에 의지해야 하고, 실제 프로젝트에 투입되었을 때 시행착오가 일어나는 경우가 상당히 많다. 이 책은 이렇게 어려움을 겪고 있는 국내의 수많은 Java 개발자들에게 도움을 주기 위해 집필되었다. 쉽고 체계적인 설명과 다양한 예제를 통해 테스트 주도 개
- 저자 : 채수원
- 출간 : 2010-06-08
테스트 주도 개발 : 고품질 쾌속개발을 위한 TDD 실천법과 도구 - 채수원
TDD 적용이 잘된 프로젝트 성공적인 프로젝트는 왠지
토끼와 거북이의 경주에서 거북이가 느리지만 토끼간까지 챙겨가는 성공적인 경주가 아닐까 하는 생각이 드네요!^_^
이전부터 TDD에 대해서 이론적으로만 얇게 알고 있었는데
개인적으로 책을 통해서 한걸음 더 다가가는 계기가 되었다.
현재까지 개발할 때면 항상
1. MFC나 C#, VB 같은 경우에는 개발이나 수정시 MessageBox 를 이용하며 값을 확인하는 방식.
2. Java, FLEX 나 Python 같은 경우엔 시스템 출력하는 방식이나
3. 클래스 내에 임의로 main 을 만들어서 모듈을 테스트 하는 방식.
4. Python 을 제외하고는 디버그로 중단점을 이용하여 처리를 하는 방식.
5. 값 체크 용도로 ValidationMethod 를 만든다거나 하는 방식.
이런 방법을 이용해서 Test를 하면서 개발을 하였었었다.
그런데 이번에 TDD를 책을 통해 접하게 되면서 TDD에 쓰는 프레임워크들을 좀더 사용해 볼까한다.
개인적으로 위와같이 개발환경이 너무 다양하고 누구나 그렇듯 일정이 빠듯한 경우도 있기 때문에
TDD를 적용한다면 특정 모듈과 같은 컴포넌트로 적용범위가 나오지 않을까 생각한다.
개인적인 업무와 관련지어 TDD를 생각하면 기존업무에는 TDD 적용이 거의 불가능 한점이 있다.
몇년에 걸쳐 TDD를 적용하지 않은 패키지를 개선 및 기능 업데이트 등을 하고 있기 때문에 힘든점들이 많다.
TDD의 경우에는 신규 Project 성격에 따라서 적용여부라든가
적용 범위를 생각해서 도입해 보는것이 다소 실무애서 다급한 일정이 아니라면
적용해 보는 것이 아닐까 생각한다.
개인적으로 책을 읽으며 리팩토링 측면에서 확실히 TDD의 장점이 있는것 같다.
SI 처럼 일정내에 마치기만 하고 정상적으로 돌아가기만 하면 끝나는
죽음의 레이서가 아니고 지속적인 패키지 제품을 개발한다면
TDD는 나쁘지 않은 선택으로 보인다.
개인적으로 공부삼아 Android AP 개발시에 TDD를 적용하여 개발해 해볼까 한다.
아직까지 적용에 의심?이 생기는 부분이 들지만
성과가 좋으면 전도사로 변신할지도!!! ^_^;
회사에서 하루 1/2을 보내거나 2/3란 시간을 보내는 개발자라면
한번 저처럼 시도를 함께 해보시길...!!
단. 업무성격이 가능하다면 말이죠. ^_^
스티브 맥코널의 프로젝트 쾌속 개발 전략(Rapid Development)에 보면
프로젝트가 산으로 가는 전형적인 실수 목록 중 아래 같은 항목이 있다.
"새로운 도구나 방법에 대한 과대평가" - 기술관련 실수 관련
식사도 천천히 하는것이 잘 채하지 않듯(전 사실 1분이면 먹을수도 있지요)
TDD 적용도 천천히 음미한 후에 적용하는 것이 최선이라고 생각하며
마무리.........
TDD 적용이 잘된 프로젝트 성공적인 프로젝트는 왠지
토끼와 거북이의 경주에서 거북이가 느리지만 토끼간까지 챙겨가는 성공적인 경주가 아닐까 하는 생각이 드네요!^_^
이전부터 TDD에 대해서 이론적으로만 얇게 알고 있었는데
개인적으로 책을 통해서 한걸음 더 다가가는 계기가 되었다.
현재까지 개발할 때면 항상
1. MFC나 C#, VB 같은 경우에는 개발이나 수정시 MessageBox 를 이용하며 값을 확인하는 방식.
2. Java, FLEX 나 Python 같은 경우엔 시스템 출력하는 방식이나
3. 클래스 내에 임의로 main 을 만들어서 모듈을 테스트 하는 방식.
4. Python 을 제외하고는 디버그로 중단점을 이용하여 처리를 하는 방식.
5. 값 체크 용도로 ValidationMethod 를 만든다거나 하는 방식.
이런 방법을 이용해서 Test를 하면서 개발을 하였었었다.
그런데 이번에 TDD를 책을 통해 접하게 되면서 TDD에 쓰는 프레임워크들을 좀더 사용해 볼까한다.
개인적으로 위와같이 개발환경이 너무 다양하고 누구나 그렇듯 일정이 빠듯한 경우도 있기 때문에
TDD를 적용한다면 특정 모듈과 같은 컴포넌트로 적용범위가 나오지 않을까 생각한다.
개인적인 업무와 관련지어 TDD를 생각하면 기존업무에는 TDD 적용이 거의 불가능 한점이 있다.
몇년에 걸쳐 TDD를 적용하지 않은 패키지를 개선 및 기능 업데이트 등을 하고 있기 때문에 힘든점들이 많다.
TDD의 경우에는 신규 Project 성격에 따라서 적용여부라든가
적용 범위를 생각해서 도입해 보는것이 다소 실무애서 다급한 일정이 아니라면
적용해 보는 것이 아닐까 생각한다.
개인적으로 책을 읽으며 리팩토링 측면에서 확실히 TDD의 장점이 있는것 같다.
SI 처럼 일정내에 마치기만 하고 정상적으로 돌아가기만 하면 끝나는
죽음의 레이서가 아니고 지속적인 패키지 제품을 개발한다면
TDD는 나쁘지 않은 선택으로 보인다.
개인적으로 공부삼아 Android AP 개발시에 TDD를 적용하여 개발해 해볼까 한다.
아직까지 적용에 의심?이 생기는 부분이 들지만
성과가 좋으면 전도사로 변신할지도!!! ^_^;
회사에서 하루 1/2을 보내거나 2/3란 시간을 보내는 개발자라면
한번 저처럼 시도를 함께 해보시길...!!
단. 업무성격이 가능하다면 말이죠. ^_^
스티브 맥코널의 프로젝트 쾌속 개발 전략(Rapid Development)에 보면
프로젝트가 산으로 가는 전형적인 실수 목록 중 아래 같은 항목이 있다.
"새로운 도구나 방법에 대한 과대평가" - 기술관련 실수 관련
식사도 천천히 하는것이 잘 채하지 않듯(전 사실 1분이면 먹을수도 있지요)
TDD 적용도 천천히 음미한 후에 적용하는 것이 최선이라고 생각하며
마무리.........
