00. 들어가며
테스트 주도 개발(TDD, Test-Driven Development), 말 그대로 테스트가 메인이 되는 소프트웨어 개발 방법론으로 선 개발 후 테스트가 아닌, 선 테스트 후 개발 방식을 의미한다. TDD가 반드시 필요한가 혹은 유리한 것인가에 대한 다양한 포스트들이 존재하지만, 현재 필자는 TDD가 필요하다는 입장이다. 현재 서비스 운영회사를 다니고 있고, Legacy와의 전쟁이 이어지고 있는 가운데 리팩토링 과정에서 수정으로 인한 사이드이펙트를 발생시키지 않기 위해서는 TDD를 도입하는 것이 바람직할 것이라고 생각하기 때문이다. 또한 동료들이 TDD에 대한 관심도가 상당히 높은 편인데, 스스로 많이 부족하다고 생각하여 본격적으로 TDD에 대한 공부도 함께 하고자 한다.
다른 카테고리의 게시글들은 공부한 내용을 정리하여 전달, 복습하는 목적이었다면, TDD 카테고리의 게시글들은 TDD를 잘 모르는 개발자들과 함께 성장할 수 있는 공간으로써 구성해보고자 한다. 필자 역시 공부를 시작하는 입장에서 작성하고 있으므로, 잘못된 내용이나 보탬이 될 수 있는 내용이 있다면 언제든지 피드백을 남겨 함께 성장할 수 있으면 좋을 것 같다.
켄트 백의 테스트 주도 개발이 TDD의 교과서 같은 책이지만, 먼저 찍먹을 통해 전반적인 개념을 익히고 난 다음에 해당 책으로 넘어가고자 한다. 첫 번째로 공부를 위해 선택한 책은 입문서로 추천 받은 최범균님의 테스트 주도 개발 시작하기이다.
그럼 함께 TDD의 세계로 뛰어들어 보자🚀
01. 돌아보기
TDD를 시작하기에 앞서 '나는 과연 제대로 개발하고 있었다고 할 수 있나?'를 위한 몇 가지 질문을 스스로에게 던져보자.
- 구현을 마친 뒤 테스트 코드를 작성하는가?
- 작성한다면 혹시 성공하는 테스트 케이스만 작성하지는 않았는가?
- 통합 테스트만 시행했다면, 실제 배포 전에 다른 예외 케이스를 발견한 적은 없는가?
- 코드를 지속적으로 리팩토링 하는 편인가?
필자는 온전히 다 두드려 맞았다. 코드의 재사용성을 위해 설계에는 진심인 편이지만, 위 질문들을 스스로에게 던졌을 때 효율적으로 코드를 작성하고 있다는 생각이 들지 않았다. 그리고 과연 정말 내가 설계에 진심이었던 것일까라는 의구심을 갖게 되었다. 너무나도 당연한 사실이지만 종종 우리는 '요구사항은 변한다'라는 것을 잊곤한다. 그것이 설령 구현 중일지라도 말이다. 또한 애써 부정하려 해보아도 '귀찮음'은 너무나도 큰 적이다. 구글 엔지니어는 이렇게 일한다'에서 거듭 강조하고 있는 것은 '원점회귀'다. 일련의 개발 프로세스에서 문제를 앞단에서 체크하고 수정할수록 비용이 줄어든다는 것이 핵심이다. 하지만 위 질문들을 통해 돌아보면, 결국 뒷 단으로 넘어가서야 수정이 들어가는, 높은 비용을 발생시키는 프로세스로 개발을 하고 있었다는 생각을 하게 되었다.
하지만 TDD를 통해 개발한다면, 이 고질병들을 어느 정도 개선할 수 있다. 물론 만병통치약은 아니다. 테스트코드를 작성할 필요가 없을 정도로 당연한 것을 TDD로 작성한다면 더 많은 비용이 발생한다는 문제점도 있다. 하지만, 실패 케이스들을 테스트를 통과시키기 위해 작성하고 개선하는 과정을 통해서 최종적으로는 리팩토링 그리고 Java 라면 보다 객체지향스럽게 추상화 과정까지 함께 할 수 있으므로, 전체 프로세스에서는 비용을 줄일 수 있게 된다. 그럼 정말 TDD가 효용을 줄 것인지 알아보기 위해 다음 포스트에서 예제 코드와 함께 본격적으로 시작해보자.
