개요
내가 경험한 그동안의 프로젝트들은 기획 - 구현 - 배포의 과정을 거쳐 진행됐다. 대략 6주정도 진행되는 소규모 프로젝트에서 1~2주 정도 기획에 할애하고, 3주동안 개발하고, 남은 시간 발표를 준비했던 것 같다. 그러다보니 당장 눈 앞의 구현을 빠르게 쳐내느라 어떤 코드가 좋은 코드인지, 어떤 게 좋은 설계인지 고민하거나 공부하는 시간이 없었다. 실제로 좋은 코드는 무엇인지, 그게 왜 좋은 것인지 설명할 자신이 없다. 그래서 이번 프로젝트에서는 내 부족한 부분을 채우고자 결심했다.
좋은 코드가 무엇일까
좋은 코드란 무엇일까 공부하다가 많은 사람이 테스트하기 좋은 코드를 좋은 코드로 분류하는 경우를 많이 봤다. 예를 들면, Spring에서 의존성을 주입하는 방법이 대표적으로 setter, 필드, 생성자 주입 3가지가 있다. 이 중 테스트에 용이하고, 불변 객체를 보장하는 생성자 주입이 권장된다.
그동안은 생성자 주입이 좋다고 하니까 관성적으로 따르기만 했지, 왜 좋은지 직접 체감하거나 설명할 수는 없었다. 실제로 단위 테스트나 통합 테스트를 제대로 작성해본 적도 없어서, 생성자 주입이 테스트에 어떤 이점을 주는지 경험하지 못했다. 그래서 이번 프로젝트에서는 단순히 구현만 빠르게 끝내는 게 아니라, 테스트 가능한 구조를 고민하고, 왜 그런 설계가 더 나은지 스스로 납득하며 개발하는 것을 목표로 삼았다.
TDD ≠ 테스트 코드 짜기
TDD는 단순히 테스트 코드를 짜는 것만 얘기하는 것은 아니다. TDD는 xP 개발론의 일종으로 켄트백이 제시하였는데, 실제 돌아가는 코드를 작성하기 전에 해당 동작을 검증하는 테스트부터 작성하는 것이다. 사실상 Test First Development와 같다고 생각해도 된다. 그렇다면 구현 전에 테스트를 작성하는 TDD가 구현 이후 테스트를 작성하는 Test Last Development와 어떤 차별점이 있을까.
구현 전에 테스트를 작성하기 위해선 반드시 고민해야 하는 게 있다.
- 내가 정확히 어떤 기능을 개발하려는가?
- 그 기능을 어떻게 테스트 할 것인가?
위의 사항을 고민하다 보면 어쩔 수 없이 아래와 같은 효과가 생긴다.
- 하나의 기능만을 수행하는 결합도가 낮은 설계를 하게 되고, 테스트하기 수월한 구조를 고민하게 된다.
- 실패하는 테스트 코드를 먼저 작성하고 이를 통과하는 코드를 후에 작성하게 되면서 내가 어떤 걸 개발해야 하는 지 명확한 상황에서 필요한 부분만 개발하게 된다.
TDD는 단순히 테스트의 유/무 혹은 테스트 작성 시점의 차이가 아니라 기능을 구현하기 전에 내가 작성할 코드는 어떤 동작을 해야하고, 해당 기능이 잘 동작하는 지 검증하는 방법을 미리 고민하는 개발 접근법이다.
맺음말
원래 TDD가 무엇인지 설명하는 글을 작성하려고 했는데, 이번 프로젝트에 TDD를 왜 적용하게 됐는지 서술하는 글이 됐다. 실제로 개발해보고 TDD를 어떻게 잘 적용하려고 했는지 작성하는 게 좋을 것 같아 다음 주 기술 블로그에 기술 하겠다.
참고자료
TDD로 앞서가는 프론트엔드: 디자인, API 없이도 개발을 시작하는 방법 / if(kakaoAI)2024
TDD, 코드 품질에 신경쓰는 회사는 몇 프로나 될까?
