오늘은 우리가 작성한 코드가 실무에서 터지지 않도록 지켜주는 테스트 전략에 대해 이야기해볼게. 면접이나 실무에서 "테스트 코드 작성해 보셨나요?"라는 질문을 받으면 대부분 JUnit으로 단위 테스트 몇 개 짠 걸 떠올리곤 하잖아? 하지만 시니어들이 보고 싶어 하는 건 단순한 단위 테스트가 아니라, 시스템 전체를 안정적으로 유지하기 위한 영리한 전략이거든.
1. 테스트 피라미드와 70/20/10 법칙 이해하기
내가 12년 동안 백엔드 개발을 하면서 가장 많이 본 실수가 뭔지 알아? 바로 모든 테스트를 E2E(End-to-End)나 통합 테스트로만 해결하려는 거야. 이렇게 하면 테스트 실행 속도가 너무 느려지고, 조금만 코드를 고쳐도 테스트가 깨져서 결국 아무도 테스트 결과를 안 보게 돼.
그래서 우리는 테스트 피라미드 모델을 머릿속에 넣어두어야 해. 구글에서 제안한 70/20/10 법칙을 참고하면 좋은데, 전체 테스트의 70%는 빠르고 가벼운 단위 테스트(Unit Test), 20%는 DB나 외부 API와의 연동을 검증하는 통합 테스트(Integration Test), 나머지 10%는 실제 유저 시나리오를 검증하는 E2E 테스트로 구성하는 거지. 이렇게 비율을 유지해야 배포 파이프라인(CI/CD)이 막히지 않고 빠르게 돌아가거든.
2. 단위 테스트는 핵심 비즈니스 로직에 집중하기
단위 테스트를 짤 때는 스프링(Spring) 컨텍스트를 띄우지 않고, 순수한 자바 객체나 Mockito를 활용해 Mocking하는 것이 핵심이야. 컨텍스트를 띄우는 순간 테스트 속도가 기하급수적으로 느려지거든.
특히 주문 금액 계산, 할인 정책 적용 같은 핵심 도메인 비즈니스 로직은 테스트 커버리지를 100% 목표로 꼼꼼하게 작성해야 해. 입력값의 경계 조건(Boundary Value), 예를 들어 빈 값이나 음수가 들어왔을 때 예외 처리가 잘 되는지 단위 테스트로 확실히 짚고 넘어가야 실무에서 대형 사고를 막을 수 있어.
3. 통합 테스트와 E2E 테스트의 영리한 활용
그렇다면 통합 테스트와 E2E 테스트는 언제 써야 할까? 데이터베이스에 실제로 데이터가 잘 들어가는지 확인하는 Repository 레이어 테스트나, 외부 결제 API와의 연동처럼 시스템 간의 접점을 검증할 때 통합 테스트를 사용해야 해.
그리고 E2E 테스트는 사용자의 핵심 시나리오(예: 로그인 -> 장바구니 담기 -> 결제 완료) 딱 몇 가지만 추려서 작성하는 게 좋아. E2E는 네트워크 상태나 외부 환경의 영향을 많이 받아 쉽게 실패(Flaky Test)하기 때문에, 최소한의 핵심 흐름만 검증하는 것이 실무적인 지혜야.
💡 핵심 정리
- 70/20/10 법칙: 단위 테스트 70%, 통합 테스트 20%,
E2E테스트 10%의 황금 비율을 기억하자.- 빠른 피드백: 단위 테스트는 스프링 컨텍스트 없이 순수 객체와
Mockito로 빠르게 실행되도록 짜자.- 핵심 흐름 검증:
E2E테스트는 비용이 크므로 로그인, 결제 같은 핵심 사용자 시나리오에만 제한적으로 적용하자. 테스트 코드는 단순히 코드 커버리지 숫자를 채우기 위한 숙제가 아니야. 나와 동료가 작성한 코드를 믿고 배포할 수 있게 해주는 가장 강력한 안전장치라는 걸 잊지 마. 오늘 작성하는 코드부터 아주 작은 단위 테스트 하나라도 제대로 짜는 습관을 들여보자.