로컬 테스트 자동화 + JaCoCo 도입으로 테스트 커버리지 끌어올리기

배포 안정성을 높이고 회귀(regression)를 빠르게 잡기 위해, 로컬에서 표준화된 테스트 실행 경로를 만들고 JaCoCo로 커버리지를 수치화/시각화하는 작업을 진행했습니다. 결과적으로 자주 호출되는 Service 레이어의 테스트 커버리지가 30%대 → 70%대로 크게 상승했고, 전체 커버리지도 유의미하게 개선되었습니다.

배경: “배포할 때만 테스트 돌리는 문화”의 한계

기존에는 테스트 실행이 팀별 배포 과정에 묶여 있었습니다. 이 방식은 다음과 같은 문제가 있었습니다.

테스트가 쉽게 깨짐: 팀/환경별 설정 차이로 인해, 로컬에서는 괜찮았던 테스트가 배포 시점에 깨지거나 반대의 경우가 생겼습니다.
커버리지 관리가 어려움: 테스트가 “어느 정도 작성되어 있는지”를 지속적으로 확인하기 어렵고, 개선의 기준선(베이스라인)이 없었습니다.
심리적 동기 부족: 숫자로 보이지 않으면 관리되지 않기 쉽고, 테스트를 “꾸준히 붙여나가는 루틴”이 만들어지기 힘들었습니다.

그래서 먼저 “테스트를 누구나 쉽게, 동일한 방식으로 돌릴 수 있게” 만드는 자동화부터 시작했고, 그 다음 “커버리지를 보이게” 만들어 개선을 가속했습니다.

1) 로컬 테스트 실행을 쉘 스크립트로 표준화

핵심은 “로컬에서 한 번에” 테스트 및 리포트를 생성하는 단일 진입점(Entry Point) 을 만드는 것이었습니다.

이렇게 해두면 팀/개인마다 실행 방식이 달라지는 것을 줄이고, “테스트를 돌리는 행위” 자체가 훨씬 가벼워집니다.

2) JaCoCo로 커버리지 “수치화 + 시각화”

JaCoCo를 도입한 이유는 단순합니다.

커버리지를 숫자로 보이게 하면,
테스트를 붙여나가면서 개선이 눈에 보이고,
결국 “관리해야겠다”는 압력이 자연스럽게 생깁니다.

특히 JaCoCo의 HTML 리포트는 패키지/클래스/메서드 단위로 Instruction/Branch 커버리지가 바로 보여서, “어디가 비어있는지”를 찾는 속도가 빨라졌습니다.

3) 적용 결과: 커버리지 개선(전/후)

아래는 JaCoCo 리포트의 전/후 비교입니다.

전체 Instruction 커버리지: 27% → 67%
전체 Branch 커버리지: 21% → 42%
Service 패키지 Instruction 커버리지: 43% → 73% (실제 체감으로는 “자주 쓰이는 서비스 메서드” 기준 30%대 → 70%대까지 올라갔습니다)

왜 Service부터 올렸나?

커버리지를 “균등하게” 올리기보다, 실제 장애/회귀를 가장 많이 만드는 지점부터 쌓는 게 효율적이었습니다.

Service 레이어는 보통
- 핵심 비즈니스 로직
- 조건 분기(Branch)
- DB/외부 의존성 호출 경계 가 모여 있어 테스트의 투자 대비 효과가 큽니다.

따라서 초반에는 “DAO/Config까지 100%” 같은 목표보다, 핵심 서비스 메서드의 분기와 예외 흐름을 먼저 커버하는 방향으로 접근했습니다.

운영 팁: 커버리지가 “유지”되게 만드는 장치

커버리지는 올리는 것보다 유지하는 게 더 어렵습니다. 아래 장치들이 도움이 됩니다.

로컬 스크립트를 팀 표준으로 만들기: PR 올리기 전 ./scripts/test.sh 실행을 루틴화
리포트 아티팩트 공유: CI에서 JaCoCo HTML/XML 리포트를 아티팩트로 남기기
(선택) 최소 기준선(Gate) 도입: 전체가 아닌 “핵심 패키지(service 등)”에만 최소 커버리지 기준을 설정

마무리

이번 작업의 본질은 “JaCoCo를 붙였다”가 아니라, 테스트 실행 경로를 표준화하고(자동화), 커버리지를 보이게 만들어(시각화), 개선을 지속 가능하게 만든 것이라고 생각합니다.

다음 단계로는 CI에서 PR마다 커버리지 변화를 코멘트로 남기거나, 핵심 경로에 한해 최소 기준선을 걸어 회귀를 더 강하게 방지하는 방향으로 확장해볼 수 있습니다.