테스트 커버리지 100%의 함정: 신뢰할 수 있는 테스트 설계 원칙

들어가며

“우리 팀 테스트 커버리지는 90%가 넘어요!”

언뜻 듣기에는 매우 견고한 프로젝트처럼 들리지만, 실상은 조금만 코드를 수정해도 수십 개의 테스트가 깨지거나, 커버리지는 높은데 정작 중요한 비즈니스 로직에서 버그가 발생하는 경우가 허다합니다. 2025년의 개발 환경에서 테스트는 단순히 ‘작성하는 것’을 넘어 **‘유지보수 비용을 낮추고 변화를 두려워하지 않게 만드는 도구’**가 되어야 합니다.

오늘은 우리가 무의식적으로 집착했던 테스트 커버리지의 함정을 파헤치고, 진짜 의미 있는 테스트 설계 원칙을 공유합니다.

1. 커버리지 숫자가 당신을 속이는 방법

테스트 커버리지는 도구일 뿐 목적이 아닙니다. 숫자에 매몰될 때 발생하는 대표적인 부작용들이 있습니다.

구현 세부 사항에 결합된 테스트: 내부 함수 하나만 바꿔도 테스트가 깨진다면, 그것은 테스트가 아니라 ‘코드 복사본’에 불과합니다.
의미 없는 검증(Assertion): 단순히 함수가 호출되었는지만 체크하고, 실제 결과값이 올바른지는 검증하지 않는 테스트들이 커버리지를 채우게 됩니다.
비즈니스 가치와의 괴리: 단순한 Getter/Setter 테스트로 커버리지를 높이는 동안, 복잡한 예외 상황(Edge Case)은 방치되곤 합니다.

2. 무엇을 테스트할 것인가? (Behavior over Implementation)

가장 중요한 원칙은 ‘구현’이 아니라 ‘행위’를 테스트하는 것입니다. 사용자가 시스템을 어떻게 사용하는지에 집중해야 합니다.

나쁜 예: 내부 상태 검증

it('유저의 상태를 active로 변경한다', () => {
  const user = new User();
  user.activate();
  expect(user.__internalState).toBe('active'); // 내부 프로퍼티에 접근
});

좋은 예: 외부로 드러나는 행위 검증

it('활성화된 유저만 게시글을 작성할 수 있다', () => {
  const user = new User();
  user.activate();
  expect(user.canPost()).toBe(true); // 외부 인터페이스(행위)를 검증
});

3. 테스트 코드의 가성비 따지기

모든 코드를 테스트할 필요는 없습니다. 투입 노력 대비 신뢰도 상승폭이 큰 지점을 공략해야 합니다.

도메인 로직 (핵심): 비즈니스 규칙이 복잡한 곳은 단위 테스트(Unit Test)로 촘촘하게 검증합니다.
외부 시스템 통합: API 호출이나 DB 연동은 통합 테스트(Integration Test)로 흐름을 확인합니다.
단순 UI/보일러플레이트: 자주 바뀌고 로직이 없는 단순 마크업은 테스트 비용이 더 클 수 있습니다.

4. 유지보수하기 좋은 테스트를 위한 팁

DAMP(Descriptive And Meaningful Phrases) 원칙: 테스트 코드는 DRY(중복 제거)보다 가독성이 더 중요합니다. 테스트만 보고도 이 기능이 무엇인지 이해할 수 있어야 합니다.
모킹(Mocking) 최소화: 모킹이 많아질수록 테스트는 실제 환경과 멀어집니다. 가능하다면 실제 객체나 가벼운 인메모리 DB를 활용하세요.
테스트 파일도 코드다: 프로덕션 코드만큼이나 테스트 코드의 품질(Naming, Structure)을 관리해야 합니다.

마치며

테스트 커버리지 100%는 달성하기 어렵지도 않고, 그 자체로 완벽을 보장하지도 않습니다. 중요한 것은 **“내가 이 코드를 리팩토링했을 때 테스트가 나를 지켜줄 것인가?”**라는 확신입니다.

오늘 여러분의 테스트 코드를 한 번 돌아보세요. 혹시 변화를 방해하는 족쇄가 되어 있지는 않나요? 좋은 테스트는 개발 속도를 늦추는 것이 아니라, 오히려 더 빠르게 달릴 수 있게 만드는 추진력이 됩니다.