배경

지난 포스팅에서 언급한 것 처럼, 요즘 서버 팀은 유닛 테스트 코드 작성을 통한 비즈니스 로직을 다시 한 번 검증하고 있다. "돌다리도 두들겨 보고 건너라"라는 말 처럼 아무리 코드가 안전하다고 하더라도 항상 조심해야 한다고 생각한다.

게다가 새로운 요구사항을 기존 코드에 반영하는 일이 종종 발생했다. 개발 하면서 Swagger를 통해 생각 나는 엣지 케이스들은 다 점검을 하지만, 그 코드에 있는 모든 조건문을 일일히 검증 하기에는 한계가 분명 존재한다. 그렇다고 이를 소홀히 할 순 없다.

이전에 “내 선호 지역별 스터디 조회” 기능에서 정말 엉뚱한 스터디가 조회된다는 이슈를 전달 받은 적이 있다. 내가 선호하는 동네는 “서울시 강남구”라면, 갑자기 뜬금 없는 “전라남도 여수시”의 스터디가 조회되는 문제가 발생했다. 원인은 리팩토링 과정에서 필터링 조건이 제대로 적용되지 않았기 때문이었다. 해당 지역에 스터디가 존재하지 않으면 “지역 코드 순”으로 모든 스터디를 조회 하는 문제가 발생했다.

이런 이슈가 제보 될 때 마다 내가 한 번 더 자세히 봤으면 충분히 파악할 수 있었을텐데 하는 아쉬움이 항상 남는다. 그래서, 요즘 서버 팀 일정이 타이트하지도 않고 해서 팀원들에게 Unit 테스트 코드를 작성 하면서 비즈니스 로직을 다시 한 번 검증 해보면 어떨까 제안 했다. 내가 짠 코드를 다시 보면서 누락된 조건은 없는지, 불필요한 코드는 없는지 확인 하면서 코드의 퀄리티도 개선할 수 있고, 위와 같은 문제도 함께 해결할 수 있을 것이라 판단했다!

적용

먼저, 각자 담당 파트 중, 핵심 기능들 위주로 먼저 검증 하기로 했다. 내 경우는 다양한 필터링을 통한 스터디 조회 기능이었다. 아래는 내가 작성한 테스트 코드 일부이다.

현재, 해당 기능에 대해 약 69개의 테스트 코드를 작성 했다. 하지만 테스트 코드가 해당 코드를 얼마나 커버하고 있는지 파악 하기에는 갯수라는 단위는 와닿지 않았다. 단순히 많이 작성하는 것이 최선일까 의문이 들었고, 이를 수치화 할 수 있는 방안을 찾아보자 생각했다.

JaCoCo

필요성을 느낄 때마다 이를 해결하는 솔루션이 있는 경우가 많다! JaCoCo가 내겐 이런 경우였다. JaCoCo는 Java 진영의 테스트 커버리지 분석 도구로, 테스트 코드가 해당 메서드를 얼마나 커버하고 있는지 수치화 하여 나타낸다.

배달의민족 블로그에서도 이를 사용하는 사례를 확인할 수 있다.

그래서 SPOT도 이를 적용하면 커버리지를 한 눈에 볼 수 있어 생산성을 더 향상시킬 수 있을 것이라고 생각했고, 이를 제안했다!

어느 정도의 커버리지를 유지해야 할까?

이제 테스트 커버리지를 수치화 하는 것 까지 성공했다. 그럼, 어느 정도의 커버리지를 유지하는 것이 좋은 선택일까? 보통은 80% 정도를 유지 하는것을 목표로 한다고 한다. 하지만 높으면 높을 수록 장점은 존재한다고 생각한다.

SPOT은 우선 80%의 커버리지를 유지 하도록 목표를 설정했다. 아직 테스트 코드가 작성되지 않은 기능들이 많기 때문에 커버리지를 통해 빌드를 실패하게 하는 등 이런 부분은 설정하지 않았다.

내가 담당하고 있는 “스터디 조회” 기능에 대해서는 현재 약 86%의 테스트 커버리지를 유지하고 있다!

참고 영상: 토스뱅크 서버 개발자 이응준님의 발표에서 테스트 커버리지를 100% 달성한 사례를 접했다. 높은 커버리지를 유지하며 얻은 이점에 (아주 조금) 공감할 수 있었다!

이점

위의 발표 영상의 내용과 연결지어 말하자면, 제일 먼저 비즈니스 로직에 대한 이해도를 크게 높일 수 있었다. 코드에 대한 이해 없이 테스트 코드를 작성 한다는 것은 정말 어렵다고 생각한다. 자연스럽게 핵심 비즈니스 로직에 대한 이해도가 높아 졌고, 이는 협업 효율성을 향상 시켰다.

그리고 테스트 코드가 기준점 역할을 한다. 이를 통해 더욱 과감한 코드 리팩토링이 가능하다. 불필요한 코드 역시 과감하게 삭제 함으로써 코드의 가독성도 크게 개선할 수 있었다.

테스트 코드 작성은 단순한 검증 작업을 넘어 코드 품질과 생산성을 높이는 중요한 작업임을 실감할 수 있었다.