최근에 사수님께서 "이제 00도 테스트코드를 짜면서 코드를 짜보세요." 라고 하셨다.

그래서 당연히 넵 :) 이라고 답했다.

근데 "테스트코드를 먼저 짜면서 코드를 작성해보세요" 라고 하셨다.

나 : ???

입사 전에도 테스트코드를 짜보긴 했고, TDD(Test-Driven-Developement)라는 걸 들어보긴 했었다. 근데 이제 사수님이 TDD는 테스트코드를 먼저 짜보면서 코드를 작성하는 거라고 하시면서 한 번 해보라니까 감이 안 잡혔다. 그래서 한 번 TDD를 왜하는 거고, 어떻게 하는지 찾아보기로 했다.

그래서 TDD 왜 해야하는 거야?

전에 혼자 DRF를 이용해서 asset-dashboard라는 프로젝트를 혼자 진행했던 후기 글에서도 언급했듯이 점점 기획의 중요성을 느꼈다. 그래서 어떤 기획이 좋은 기획인가?를 찾아보면서 여러 글을 보았는데 그 중 이런 글귀가 있었다. "가설 베이스 사고를 하는 것이 논리적 사고를 하는데 있어서 중요하다. 늘 결론을 갖고 그에 대한 가설을 검증하는 방식으로 사고해야 한다" 이 글귀가 정확히 TDD가 가고자 하는 방향을 설명하는 것 같았다.

테스트코드를 먼저 짜므로서 가설을 설정하고, 내가 짠 코드로 그 가설을 검증하는 것이다.

그리고 이런 방향으로 개발하기 위해서는 "검증하고자 하는 가설은 무엇인가?" 이게 핵심 질문이였다. 즉, "테스트하고자 하는 것이 무엇인가"이다. 생각해보면 이전에 간단하게 테스트코드를 짤 때는 request를 날리고 requests.code.ok가 떴는지 이런걸 체크하기 위해 테스트코드를 짰었는데 이런게 무의식 중에 생각하게 되는 아주 작은 가설 ('내가 이렇게 request를 날리면 200이 올 것이다!") 중 하나였던 것 같다. "

이렇게 하면 테스트코드를 먼저 짜야하니까 미래에 일어날 버그들을 생각하게 되고, 코드부터 짜고 테스트를 하는 것보다 나중에 생길 버그나 개선해야 할 것들을 더 생각하게 되는 것 같았다. 그리고 결과적으로 모두가 원했던 버그는 줄고 코드는 간결해지는 clean code라는 목표에 다다르게 되는 것 같았다.

마지막으로 이런 이유로 TDD를 하는 것이고, TDD를 하면 미래에 유지보수하는 시간이 매우 줄 것이라고 생각한다. 그래서 기능이 많은 큰 프로젝트에서는 TDD가 중요할 것 같다. 근데 해보니까 TDD를 하면 개발하는 시간이 엄청나게 늘어 날 것 같다. 기획자와 의사소통이 많이 필요하니까... 그래서 프로토타입을 만들어서 기능을 실험해보거나 휘발성이 높은 코드를 짤 때는 엄청 필요할 것 같진 않아보였다.

그래서 TDD를 어떻게 해야하나...

위의 사진처럼 설계/기획하고, 테스트코드를 먼저 작성한 다음에 코드 개발을 하는 것이다. 그리고 더 나아가서 TDD 방식이란 테스트코드를 짜면서 발생하는 예외사항들을 계속 테스트케이스에 추가하면서 설계를 개선하고 마지막에 테스트를 통과한 코드만 실제 코드로 작성하는 방식이라고 한다. 이론적으론 그렇다... :)

사실 이런 부분은 ' 아 그렇구나... 일단 이렇게 해야하는 거 같다...' 이렇게 감을 잡고 하다보면 아 '왜 이런 방식으로 하라고 가르쳐주셨구나...' 라는 걸 더 느끼게 되는 것 같다. 그래서 회사 내부에서 누군가 unittest로 짜놓은 test코드를 보면서 공부하고, 이전에 써보았던 pytest도 생각하면서 일단 어떻게든 해보고 있다. 꼭 알아두면 좋은 setup, setupclass나 teardown, teardownclass와 더불어서 @patch 이런 것도 다음에 글 쓰면서 정리해봐야겠다.

00pen.tistory.com/92

참고문헌

구글에서 개발한 5일 완성 기획 프로세스:  brunch.co.kr/@thinkaboutlove/87

TDD(Test-Driven-Development) 방법론에 대해서: https://wooaoe.tistory.com/33