단위 테스트와 통합 테스트를 어떻게 구분해야 할까
테스트를 작성하다 보면 가장 자주 헷갈리는 질문 중 하나가 있다.
이 테스트는 단위 테스트인가, 통합 테스트인가?
이 질문이 중요한 이유는 용어 자체보다 테스트가 어떤 책임을 가지는지를 결정하기 때문이다. 단위 테스트와 통합 테스트를 잘 구분하지 못하면 테스트는 많아지는데도 실패 원인을 찾기 어렵고, 실행 속도는 느려지고, 유지보수 비용은 커진다.
단위 테스트는 무엇을 검증하나
단위 테스트는 이름 그대로 작은 단위의 동작을 검증한다.
여기서 말하는 단위는 보통 다음 중 하나다.
- 메서드
- 클래스
- 도메인 규칙
- 순수 함수
핵심은 테스트 대상 외부의 영향을 최대한 줄인다는 점이다.
예를 들어:
- 할인 금액 계산
- 상태 전이 검증
- 입력값 검증 로직
같은 것은 단위 테스트에 잘 어울린다.
통합 테스트는 무엇을 검증하나
통합 테스트는 여러 구성 요소가 함께 동작할 때 기대한 결과가 나오는지를 본다.
예를 들어:
- 서비스와 리포지토리의 연결
- DB 저장과 조회
- 메시지 발행 후 처리 결과
- HTTP 요청부터 응답까지의 흐름
즉, 통합 테스트는 “이 메서드가 맞는가”보다 “이 구성들이 붙었을 때 시스템이 제대로 작동하는가”를 검증한다.
가장 큰 차이: 실패 원인을 좁히는 속도
단위 테스트가 실패하면 보통 원인을 빠르게 좁힐 수 있다.
- 입력과 출력이 명확하다
- 외부 의존성이 적다
- 실행 속도가 빠르다
반면 통합 테스트가 실패하면 확인해야 할 범위가 넓다.
- 설정 문제인가
- DB 상태 문제인가
- 트랜잭션 문제인가
- 직렬화 문제인가
그래서 단위 테스트와 통합 테스트는 경쟁 관계가 아니라 역할 분담 관계다.
무엇을 단위 테스트로 우선 가져가야 하나
다음 성격의 코드는 단위 테스트로 가져갈수록 좋다.
- 조건 분기가 많은 로직
- 계산 규칙이 있는 코드
- 도메인 상태 전이
- 예외 발생 규칙
이런 코드를 통합 테스트에만 의존하면, 테스트는 느리고 디버깅도 어려워진다.
무엇은 통합 테스트로 남겨야 하나
반대로 다음은 통합 테스트가 필요하다.
- JPA 매핑 검증
- 실제 SQL 동작 확인
- 트랜잭션 경계 검증
- HTTP 요청/응답 직렬화 검증
- 외부 시스템 연동 계약 확인
이 영역은 목 객체만으로는 놓치는 문제가 많다. 즉, 통합 테스트는 느리지만 대신 실제 환경과 더 가까운 위험을 잡는다.
흔한 오해
목을 쓰면 모두 단위 테스트인가
그렇지 않다. 외부 의존성을 대체했다고 해도 테스트 범위가 여러 계층을 넓게 포함하면 단위 테스트라고 보기 어렵다. 반대로 DB 없이도 명확한 책임 단위를 검증하면 단위 테스트라고 볼 수 있다.
통합 테스트만 잘 쓰면 단위 테스트가 필요 없나
그렇지 않다. 통합 테스트만으로 모든 로직을 커버하려 하면 실행 시간이 길어지고 실패 분석이 어려워진다. 세밀한 규칙 검증은 단위 테스트가 훨씬 적합하다.
실무적인 균형
실무에서는 보통 이런 식의 균형이 유효하다.
- 도메인 규칙과 계산은 단위 테스트로 촘촘하게
- 저장소, API, 트랜잭션은 통합 테스트로 핵심 경로만
즉, 개수보다 분리가 중요하다. 단위 테스트는 빠른 피드백을, 통합 테스트는 실제 연결 지점의 안정성을 담당한다.
예시로 보면 더 명확하다
예를 들어 주문 생성 기능이 있다고 하자.
단위 테스트로 볼 것:
- 주문 가능 상태인지 판단
- 할인 정책 계산
- 잘못된 입력일 때 예외 발생
통합 테스트로 볼 것:
- 주문 저장 후 DB에 정상 반영되는지
- 주문 API 호출 시 응답 형식이 맞는지
- 트랜잭션 처리 후 이벤트가 발행되는지
이렇게 나누면 테스트가 왜 필요한지와 실패했을 때 어디를 봐야 하는지가 훨씬 분명해진다.
정리
단위 테스트와 통합 테스트의 차이는 “작다 / 크다”가 아니라 무엇을 책임지고 검증하느냐다.
- 단위 테스트: 규칙과 로직의 정확성
- 통합 테스트: 연결과 협력의 정확성
테스트 전략이 좋은 팀은 둘 중 하나만 고집하지 않는다. 빠르게 실패를 알려주는 단위 테스트와, 실제 구성의 문제를 드러내는 통합 테스트를 각자 맞는 자리에 둔다. 그 구분이 명확할수록 테스트는 많아도 유지하기 쉬워진다.
댓글
아직 댓글이 없습니다