"TDD( Test Driven Development )" 말그대로 테스트를 기반으로 코드를 개발해나가는 과정이다.
현재 나는 사이드 프로젝트로 진행하고 있는 프로젝트에서 API server를 개발중이고, 그 API 서버를 TDD를 이용하여 개발하고 있다.
테스트 코드의 중요성은 여러 곳에서 많이 들어서, 이번 개발에서 한 번 시도해보자하고 시작했는데..
참.. 이게 좋은데, 어렵다.
장점
놓칠 수 있었던 부분을 사전에 방지해준다
이 부분은 정말 좋은 장점이다.
평소에 개발을 혼자 진행하면서, 이 정도면 괜찮겠지..? 했는데, 꼭 하나씩 빼먹었던 것이 있었다.
하지만, 이번 개발에서는 그런 것이 거의 없었다. ( 거의.. 거의.. 당연히 빼먹는건 무조건 존재할 수 밖에 없다. 나는 완벽한 존재가 아니니까. )
사전에 어떠한 Controller에 대해 이러한 부분에서는 성공해야해! 이런 부분에서는 실패했다고 응답해야해! 이런식으로 미리 테스트를 작성하고, 그에 따라 코드를 작성하면서 실시간으로 테스트의 결과를 보게되니까 당연히 놓치는 부분은 줄어들 수 밖에 없다.
디버깅의 시간이 줄어든다
당연히 줄어든다.
이미 정해놓은 테스트에 대해 나는 그것을 구현할 뿐이고, 거기서 놓치는 부분이 있으면 테스트 코드가 잡아준다. ( 물론 테스트 코드에서 문제가 없다는 가정하에 )
당연히, 코드를 디버깅하게 되는 시간이 줄어들었다.
테스트 커버리지가 높아진다.
테스트 코드를 먼저 작성하고, 그에 따른 개발을 하게 되니 당연한 결과.
그에 따라, 필요 없는 부분이 줄어들게 된다.
단점
내가 테스트를 잘 작성하고 있는지 잘 모르겠다.
사실 이건 TDD의 단점이 아니다.
정확히 TDD의 단점이라고 말하려면, 진입장벽이 높다? 이런식으로 표현해야 할 것 같다.
우리나라에서 TDD에 관한 책을 검색하거나, 관련 자료를 찾아보자.
일단, 알라딘에서 TDD라는 검색어로 검색을 해보았다.
통합 57건 나온다. 여기서 중복되는 E-book을 제외하고, 여러 잘못 나온 책들을 제거하면 40건 정도로 수렴한다.
이 말이 무슨 말이냐? 정보가 없다시피하다.
그건 또 무슨 말이냐? 내가 짠 테스트 코드가 제대로 짠 테스트 코드인지 확신 할 수 없다.
테스트 코드를 작성하면서..
제대로 잘 작성한건지?
정말 개발을 위한 테스트 코드를 작성하는게 맞는지?
그냥 정말 테스트를 위한 테스트를 하는게 아닌지?
이런 의문이 들 때가 정말 많았다.
하지만, 이런 것에대한 피드백을 받을 수 있는 곳이 1도 없다는게 문제다.
정말 어렵다.
마무리하면서
그럼에도 불구하고, 우리나라에는 TDD를 정말 잘 활용하는 사람들이 많을 것이다.
그런 사람들이 강연도하고 블로깅도하고 책도 쓰고.. 하면서 사람들에게 자신의 생각을 전파할 것이다.
그런 것을 보면서 나는 더 생각을 정리하고, 공부하고 배워나가야 할 것이고.. 노력해야 할 것이다.
TDD를 시작하려는 여러분들에게 추천드리는 영상과 글들을 추가로 남기고 글을 마치겠다.
참고
