소프트웨어 업계에서 대형포털, 몇몇 개발사를 제외하면 TDD 를 아직 도입하지 않는 회사가 더 많은 것이 현실이죠. 이런 소프트웨어 개발사에서는 TDD를 도입할때의 두려움과 실효성에 대한 의문점때문에 도입을 꺼려 하는데요.
이책은 TDD 를 도입해야 하는 이유와 논리적인 방법에 대해 조목조목 설명하고 있습니다. 도입방법에 촛점을 맞추기 보다는 TDD에 대한 전반적인 개념과 당위성을 설명하고 설득하네요. 마치 TDD 전도사의 얘기를 듣는 느낌이랄까요? 좋은점은 부각되는데 단점은 말하지 않는 느낌도 있어요.
반면, 이책이 가지는 장점은 TDD, 디자인패턴, 리펙토링등 광범위한 분야를 다루고 있어 고급개발자에게 필요한 지식들을 개략적으로 버무려 놓았다는 점. TDD 와 함께 소프트웨어 개발 전반에 대한 지식을 습득할수 있다는 점. 등이 유익했습니다.
아쉬운 점은 이러한 업체들이 TDD를 도입할때 필요한 것들에 대한 내용들이 다루어졌다라면 더 좋았을거 같아서.. 별 4개.!! 더불어 조직이슈때문에 전사적으로 TDD 를 도입할 수 없는, 개인이 시도해 볼수 있을만한 TDD 방법을 제안해주시면 더 좋은 TDD 전도사로써의 책이 되지 않을까 생각해봅니다.
3.8점 (4명)
좋아요 : 34
TDD 때문에 좌절을 경험한 개발자에게 들려주는 TDD 이야기!
테스트 주도 개발(Test-Driven Development)이라 불리는 TDD는 개발자 사이에서 많은 이슈가 되었고, 현재도 관심을 많이 받고 있다. 하지만 TDD의 유명세에도 불구하고, TDD를 실제로 적용해보거나 학습해보려는 관심과 호기심은 부족하다. 왜일까? 아마도 TDD에 대한 잘못된 지식이나 고정관념, '테스트 코드를 먼저 만든다'는, 지금까지 체험하지 못한 개념 때문일 것이다. TDD가 관심을 받는 데는 분명 그만한 이유가 있다. TDD는 프로젝트 진행뿐만 아니라 개발자의 능력을 높이는 데에도 도움을 주는 것으로 알려져 있다. 하지만 TDD를 하는 것은 무척 어렵고 복잡하다는 이야기도 있다.
이 책의 저자는 TDD를 실무에 도입하면서 겪었던 좌절과 TDD에 대한 오해, 그리고 이를 해결해 나가면서 배운 것들을 담았다. 이를 통해서 TDD를 실무에 어떻게 적용할 수 있는지와 실무 팁을 배울 수 있다. 또한, TDD가 어렵고 복잡하다는 오해를 풀고, 왜 TDD를 사용해야 하는지 알게 될 것이다.
대상 독자
- TDD를 공부했으나, 여러 가지 풀리지 않는 문제점으로 인해 끙끙대는 프로그래머
- TDD 도입에 실패했지만 다른 방법을 모색하여 도입에 성공하고 싶은 프로그래머
- TDD를 두 번 다시 하고 싶지 않은 프로그래머
TDD 도입에 실패한 원인을 알아야 TDD가 보인다!
이 책은 TDD 관련 배경 지식을 기반으로 현업에서 활용되거나 이슈가 되는 문제들을 다루고 있기에 실제로 TDD를 다루며 겪는 문제의 실마리를 푸는 데 유용할 것이다. 또한, TDD와 관련한 깊이 있는 메시지와 아이디어를 제공하므로, TDD의 활용도를 한 단계 높이는 계기를 마련해줄 것이다. 예로는 자바 콘솔 애플리케이션을 대상으로 한 예제와 간단한 객체 지향이론, UML 클래스 다이어그램 정도가 인용되고 있으며, 복잡하지 않은 GoF 디자인 패턴 몇 개를 소재로 삼고 있다.
이 책은 다음과 같이 구성되어 있다.
'1장 반가워 TDD'에서는 저자의 경험을 토대로 TDD가 왜 좋으며, 왜 사용해야 하는지를 알려준다.
'2장 TDD에 관한 오해와 진실'에서는 개발자들이 TDD에 관해서 가지고 있는 오해를 풀어보고 진실이 무엇인지 알려준다.
'3장 현장 이야기'에서는 Mock 객체, Fixture, TDD와 디자인 패턴, private 메서드, 레거시 코드를 TDD에서 어떻게 사용해야 할지 알려준다.
'4장 TDD, 올바른 사용과 사용 습관'에서는 TDD를 어떻게 사용해야 하는지, 그러고 어떻게 시나리오를 구성하고 단위 테스트를 해야 할지를 알려준다.
1장. 반가워, TDD
1.1 TDD, 어디에 쓰는가?
1.2 지금 TDD가 필요하다
2장. TDD에 관한 오해와 진실
2.1 (오해 1) TDD는 비용이 더 들고, 결국 개발 속도를 저하시킨다
2.2 (오해 2) 코드 커버리지가 높으면 좋은 코드다
2.3 (오해 3) 진압보다 예방에 소비되는 비용이 높다
2.4 (진실 1) TDD != Unit Testing
2.5 (진실 2) TDD는 설계 개선에 도움을 준다
3장. 현장 이야기
3.1 Mock 객체, 언제 그리고 어떻게 사용할까?
3.2 Fixture, 어떻게 사용해야 할까?
3.3 TDD와 디자인 패턴의 아름다운 동행
3.4 private 메서드 그리고 단위 테스트
3.5 만지기 싫은 레거시 코드, TDD가 해법이다
4장. TDD, 올바른 사용과 사용 습관
4.1 Top-Down으로 방향을 잡고, Bottom-Up으로 구현에 집중하자
4.2 바보 단계 거치기
4.3 시나리오 구상하기
4.4 TDD의 단위 테스트를 문서화하자
Appendix 마틴 파울러의 "Mock은 Stub이 아니다."
Mock과 Stub의 구분을 넘어서
Driving TDD(TDD 진행 방식의 차이)
Fixture Setup(Fixture, 얼마나 어떻게 사용하는가?)
Isolation(단위 테스트 격리에 대한 관점의 차이)
Coupling Tests to Implementations(단위 테스트와 구현체의 결합도에 따른 영향)
Design Style(테스트가 설계에 미치는 영향)
다양한 시각, 점진적 사용, 그리고 성장
리얼타임 eBook 안내
PDF 형식으로 제공되며, 다운로드한 eBook은 PDF 포맷을 지원하는 디바이스 또는 프로그램에서 제한없이 열람할 수 있습니다. 또한 eBook 내의 텍스트 검색 및 인쇄도 가능합니다.
오탈자 등록
