읽은 책 소감 - 테스트 주도 개발 (TDD)

 

  대부분의 개발자들은 TDD (Test-Driven Development)보다는 TDD (Time-Driven Development)(?)에 더 익숙할 것 같다. 처음 이 책을 읽어보게 된 이유는 'TDD가 정말 좋은가?'에 대해 답을 얻기 위해서였다. 뭐 구글링하면 나오기야 하겠지만, 일단 직접 알아야 써보면서 장단점을 알 수 있는 거니깐 공부하게 되었다.

 

  대학생 때부터 난 생각난걸 코드로 옮기는 구현력(?)과 예외가 될만한 경우의 수를 미리 생각하는건 나름 자신있는편이었다. 그래서 테스트가 정말 필요한거 맞아? 그냥 잘 짜면 되는거 아님? 이렇게 생각했었다. 실제로도 테스트 없이 짜도 문제가 거의 없었다. 하지만 만든게 실제 운영될 때, 내가 운영을 안할 수 있다. 또 혼자서 만드는게 아니다. 그리고 요구사항은 언제든 바뀔 수 있다. 결정적으로 문제가 '거의' 없던거지 아예 없던건 아니다. 분명 내 예상을 벗어난 오류가 발생했다.

 

  그러니 이젠 테스트는 꼭 필요한게 맞다고 생각한다. 물론 너무 테스트 커버리지에 매몰되어 테스트 커버리지를 위한 테스트를 만드는건 별로라 생각한다. 그리고 테스트를 짠다고 오류가 완벽히 없긴 힘들겠지만, 확률은 확실히 더 낮아진다.

 

  그 후에 궁금했던게 '일단 짜고 필요한 부분을 테스트로 짜는것보다, TDD 이론대로 일단 테스트부터 짠 후 실제 구현을 짜는게 정말 더 좋은가?' 였다. 개인적인 결론은 고민할 필요가 없었다! 이다. 그냥 취향에 맞게 가면 될 것 같다. 난 POJO로 구현을 테스트쪽에서 짠 후 구현체를 옮기고, 테스트를 남기는 방식이 가장 내 스타일에 맞는 것 같다. 분명 TDD 방식은 아닌 것 같지만, POJO로 짠 후에 프레임워크를 입히는거니 또 실제 구현을 다 짜고 테스트를 짜는것도 아니다. ㅋㅋ 뭐 언젠가 좀 더 실력이 늘면 생각이 바뀔 수도 있다.

 

  아무튼 다시 책 소감으로 돌아와서, 이 책이 위처럼 생각하는데 도움을 준 책은 아니었다. 한마디로 난 이 책에서 인사이트를 거의 못 얻었다. 그래도 1부는 정말 좋았다고 생각한다. 고수인 책 저자가 생각하는 방식을 따라가볼 수 있었다는 점 만으로도 좋았다고 생각한다. 그리고 테스트쪽 얘기 뿐 아니라 객체지향 적인 면으로도 설명을 좀 해줘서 좋았던 것 같다. 하지만 이 책을 보고 TDD로 짤 수 있다! 이건 아닌 것 같다. 결국 다른걸 추가로 보긴 해야한다.

 

 

- 추천 : TDD 혹은 테스트가 뭔지 잘 몰라서 뭐부터 봐야할지 모르겠는분

- 비추 : TDD에 대한 인사이트가 필요한 분 (근데 이건 내 경우라 사람마다 다를 것 같긴 하다)

 

 

- 이 책을 보고 TDD와 객체지향 내용을 좀 섞어서 써본 글 : TDD, Mock, SOLID 얘기 - 도시 가스 요금 계산