TDD 와 함께 사내 서비스 개선하기

 

📌 TDD 를 활용해볼까?

이번에 사내에서 사용하고 있는 메일 템플릿 프로젝트를 손볼 기회가 생겼습니다.

새로운 메일 배포 방식 적용이 필요했는데, 이를 위해서는 기존 프로세스에 대한 이해가 필요했습니다.

새롭게 투입된 프로젝트에 기능을 추가하거나 수정하는 것은 영향도에 따라 쉽지 않을 수 있는 작업인데,

이번에 맡은 업무가 해당 서비스 코드 전반적으로 수정이 필요했던 작업이라 더욱 고민이 많았던 것 같습니다.

안정적인 서비스 개발 및 리팩토링을 위해 TDD 를 적극적으로 활용해볼 수 있는 좋은 기회로 보여 적용 및 후기에 관한 포스트를 작성해봤습니다.

💡 이번 포스트에서 TDD 패러다임에 대한 자세한 내용을 다루지는 않습니다.

 

🤔 TDD 란?

간단하게 TDD 에 대해서 살펴보고 가겠습니다.

TDD는 테스트코드 작성 → 기능 구현 → 테스트 -> 리팩토링 → 테스트 -> ... 의 반복된 사이클로 이루어집니다.

각각의 테스트는 독립적이고 빠르게 수행되어야하며 반복 가능하고 자체적으로 검증이 가능해야합니다.

그리고 가장 중요한 것은 테스트를 실제 코드를 구현하기 전에 작성해야 한다는 것입니다.

해당 프로젝트에는 기존에 테스트 코드가 존재하지 않아서 우선 기능 개발을 하기 전에 기존 기능들에 대한 테스트를 추가하는 것부터 시작했습니다.

 

🧪 레거시 코드에 테스트코드 추가하기

우선 하나의 운영서버 API_KEY 를 사용하는 메일링 서비스이기 때문에 테스트 격리와 일관성 보장을 위한 API 모킹이 필요했습니다.

이를 위해 각각의 테스트에서 호출하는 fetch 함수를 모킹하는 대신 msw 를 도입해서 모킹이 필요한 API 핸들러를 추가하는 방향으로 진행했습니다.

이렇게 하니 중복된 모킹 데이터도 제거되고, 테스트 대상 함수의 추상화가 온전히 보장되어 테스트코드 작성에 좀 더 집중할 수 있었던 것 같습니다. 😄

 

♻️ 리팩토링하기

기존 코드에 새로운 기능을 추가하기 전에 일부 모듈에서 좀 더 확장성 있는 구조로 변경할 수 있을 것 같은 부분들이 보였습니다.

새로운 기능을 추가하기 전에 리팩토링을 진행했는데, 테스트코드가 있는 상태에서 진행하니 회귀버그에 대응할 수 있다는 안정감과 함께 코드 수정이 가능했습니다.

실제로 리팩토링을 하다가 기존 코드를 잘못 수정해서 테스트가 깨지는 경우가 종종 있었는데, 만약 테스트가 없었다면 모르고 지나쳐서 이후 개발자 테스트 단계나 배포된 이후에 발견한 뒤 수정을 하는 병목 및 리스크가 존재했을 것 같습니다.

 

✨ 신규 기능 추가하기

신규 기능을 추가할때도 마찬가지로 테스트 코드를 먼저 작성하고 모듈을 구현했는데, 그 결과 인터페이스를 어떻게 구현하는게 좋을 지 고민을 더 많이 하게 된 것 같습니다.

클린 코드 저서에는 테스트 코드를 정의하기 어려운 함수는 악취가 나는 함수 라는 구절이 있습니다.

테스트 작성이 쉽도록 더 작은 단위로 모듈화하고, 불필요한 의존성은 제거하는 등 추상화가 잘 된 구조로 고민해보게 되는 계기가 된 것 같았습니다.

실제로 이 방식으로 진행하니 개발 후 E2E 테스트시에 별다른 이슈가 발견되지 않았습니다.

또한 테스트 코드 자체가 함수에 대한 하나의 기능명세서 와 같은 역할을 하기에 PR 을 리뷰할때도, 그리고 추후에 다른 개발자가 이 프로젝트를 수정할 일이 생겼을 때에도 어떤 목적으로 이 모듈이 추가된 것인지 명확하게 알 수 있어서 유지보수에 더욱 용이할 것이라는 생각이 들었습니다.

 

💬 느낀점 및 마무리

TDD 와 함께 현재 운영중인 서비스 리팩토링 및 기능 개발을 진행해본 결과, 확실히 안정적으로 개발하는데 도움이 많이 된 것 같습니다.

테스트 덕분에 side-effect 걱정없이 과감한 변화가 가능했고 작업 도중에 놓친 edge-case 들도 자가검증할 수 있었습니다.

다만 불필요하게 중복된 기능을 검증하는 테스트를 추가하지 않도록 주의할 필요가 있는 것 같습니다.

테스트 코드도 결국은 코드 이기 때문에, 코드에 악취가 나지 않도록 신경써주는 것이 중요할 것 같습니다.