프로젝트를 TDD로 진행하며 느낀 TDD 경험담

TDD란 무엇인가??

• TDD는 Test-Driven-Development의 약자로 말 그대로 테스트가 이끄는 개발이라는 개발 방법론이다.
• 아주 짧은 개발 사이클을 반복하며, 많은 개발자들이 채택하고있는 방법론 중에 하나이다.
  • 요구사항을 검증하는 테스트 케이스 작성 ~> 테스트를 통과하기 위한 최소한의 코드 구현 ~> 작성한 코드를 표준(요구사항 명세)에 맞도록 리팩토링
  • 테스트 케이스를 작성하고 테스트를 통과하기 위해 코드를 구현할 때, 설계 상의 오점을 빠르게 파악하여 수정하며 진행할 수 있다는 장점이 있다.

할고래DO의 TDD

API 서버에서 유닛 테스트를 검증하며 TDD 방법론을 기반으로 개발을 진행했다.

• service와 api 모두 테스트를 진행하며 TDD를 하는 것이 정석이지만, 할고래DO를 개발할 때는 API 테스트만 진행하기로 결정했다.
  • 이유 1) MVCS에서 서비스 단의 비즈니스 로직에 대한 개념이 명확하지 않기 때문에, MVC로 설계한 후에 필요하면 MVCS로 리팩토링 하는 것으로 결정
  • 이유 2) 기능 구현을 우선 순위에 두고, validation과 에러 처리는 어느 정도 API 응답이 갖춰진 이후 진행하자는 의견

실제로 TDD를 도입한 사례

• API 구현

  • 다음은 할고래DO 서비스에서 특정 유저의 모든 할일에 대한 정보를 가져오는 API를 구현할 때 진행했던 코드의 일부분이다.
  • 
  • 먼저, API 명세에 따라서 반환돼야하는 response 값을 미리 정해두고, 이에 맞추어 개발을 진행했다.
  • 이후, API URL에 따라 router에 등록하고, controller에서 요청에 대한 비즈니스 로직을 연결하고 응답 값을 반환 ~> service 단의 비즈니스로직 작성 순서로 진행했다.
    • 처음 MVC 패턴으로 진행할 때는, controller에서 비즈니스 로직을 처리했었는데, 이는 잘못된 방법이다.
    • 멘토님께서 controller의 책임이 아닌데 책임을 주었다고 말씀하셨다.
    • controller의 책임은 시스템을 사용하기 위한 인프라와 관련된 역할만을 한다 (validation 등)
    • 비즈니스 로직이란, 데이터를 어떻게 저장하고 사용할건지에 관련된 내용들을 담당한다.

• validation & 에러 처리

  • 다음은 할고래DO 서비스에서 자신의 섹션에 대한 데이터를 수정하는 API를 구현할 때 진행했던 코드의 일부분이다.
  • 
  • API 응답에 대한 예외 케이스들을 작성한 다음, router -> controller -> dto -> service 순서로 진행했다.

직접 느낀 장단점

장점

• MVC to MVCS

  • controller에서 비즈니스 로직을 service 단으로 옮기면서, 믿는 구석이 있어서 자신있게 구조를 수정할 수 있었다.
  • 또한, 연결이 잘 되었는지 테스트 코드를 실행하며 확인할 수 있었고, 문제가 생긴 부분만 수정하면 돼서 편했다.

• validation & 에러 처리

  • class-validator를 처음 써서 class-validator 데코레이터에 많이 미숙했다.
    
    공식 문서에 친절한 사용법이 많지 않고 TypeScript가 아닌 JavaScript로 사용하는 예시도 없어서 어떻게 동작하는지 직접 확인했다.
    
    미리 작성해둔 테스트 케이스 통과 여부를 확인하며 올바르게 validation을 하고있는지 유용하게 사용했다.
    
    에러 처리 또한, 제대로 에러를 잡고있는지 정의해둔대로 custom 에러가 반환되는지 유용하게 확인할 수 있었다.

• 빠른 개발

  • 하단에 언급할 단점과 대비되겠지만, 어떻게 TDD를 해야하는가에 대한 감이 온 뒤 부터는 개발 속도가 정말 빨라진다.
  • 에러 처리나 validation, 사소한 오타, 로직 등 구조가 잡히면서 리팩토링하거나 코드를 전면적으로 수정해야하는 경우가 현저히 줄어든다.
  • 무엇보다도 test code가 통과되는 것을 확인하면서 개발할 맛이 난다는 느낌을 받을 수 있었다.

• 기타

  • 위의 사항들 외에도 사소한 오타나, 로직이 잘못된 경우에 어떤 부분을 확인해야하는지 테스트 케이스에 정의해 둔 이름을 통해 역추적하며 편하게 수정할 수 있었다.

단점

• Test code를 작성해보지 않았다거나, API 테스트를 어떻게 해야하는지, db는 어떻게 해결해야하는지 잘 모르는 상태에서 새롭게 배운다는 러닝커브를 무시할 수 없다.

  • 저번 프로젝트에서 처음 TDD를 진행했고, API test를 처음 해보면서 어떻게 TDD를 해야하는지 갈피를 잘 못잡았었던 기억이 난다.
  • 하나하나 새롭게 배워야 한다는 부담감이 적지는 않은 것 같아서 단점으로 느꼈었다.

• 기획의 큰 방향이 바뀌는 경우 test code 리팩토링이 필요하다.

  • 할고래DO의 서비스는 3주, 4주 차에 큰 리팩토링을 진행했었다. 이 때, 처음에 기획했고 정의했던 사항들이 크게 변하면서 힘들었던 기억이 난다.
    
    복합적으로 수정해야하는 상황에서 테스트 코드의 전면적인 수정에 소요한 시간이 적지 않았고,

• 모든 팀에서 TDD를 적용하지 않거나 어느 케이스 범위까지 test를 진행할 것인지 논의가 되지 않은 프로젝트에서는 사용하기 힘들다.

  • 할고래DO에서는 백엔드 구현 시, TDD를 진행했는데 테스트 코드를 작성하다보니 누군가가 TDD를 하지 않는다면 해당 기능에 대한 불안감이 존재할 수 있다고 느꼈다.
    • 실제 현업에서 많은 팀들이 TDD를 쉽게 도입할 수 없는 이유가 위의 두 이유라고 한다.
  • 할고래DO에서는 어느 케이스 범위까지 test할지 정하지 않았는데, 백엔드 리팩토링을 진행하면서 올바르게 동작하는지 확인하기 힘들었다.
    
    이 경험을 토대로, 앞으로 TDD를 채택하게 된다면 검증할 케이스 범위를 미리 맞추고 진행해야한다는 것을 배웠다.

기타

TDD를 했다고 말하면서 조금 부끄럽지만, 사실 프로젝트가 마무리되는 단계에서 test coverage를 접하게 되었다.

test coverage는 현재 작성된 test code가 구현되어 있는 서비스에서 어느 수준으로 검증해주고 있는지 척도라고 생각하면 될 것 같다.

할고래DO에서는 Jest로 모듈 테스트를 진행했는데, coverage option을 제공한다.

보통은 istanbul을 이용한다고 하는데, Jest에 이 istanbul이 내장되어 있다고 한다.

사용법

• test 실행 옵션에 --coverage를 붙여주면 coverage 수치를 console에 보여주며, npm 실행과 같은 레벨의 디렉토리에 coverage라는 디텍토리를 생성해서 결과를 준다.
• 
• 실행 후에 console에 위와 같은 형식으로 어떤 파일의 어떤 부분을 테스트 하고 있고 누락되었는지 %로 표시해준다.

할고래DO의 결과

조금 부끄럽지만 처음 커버리지를 측정한 것 치고는 꽤나 높은 수치가 나온 것 같다.



불과 2달 전 쯤의 저처럼 TDD에 대해 두렵거나 어떻게 해야하는거지??? 라고 생각하는 분들에게 도움이 되면 좋겠다는 마음에 이 글을 남깁니다.

Reference

• https://ko.wikipedia.org/wiki/%ED%85%8C%EC%8A%A4%ED%8A%B8_%EC%A3%BC%EB%8F%84_%EA%B0%9C%EB%B0%9C
• https://ui.toast.com/fe-guide/ko_TEST#%EC%89%AC%EC%9A%B4-%EC%BB%A4%EB%B2%84%EB%A6%AC%EC%A7%80-%EC%B8%A1%EC%A0%95