Spring Boot 테스트 슬라이스: @WebMvcTest, @DataJpaTest
그래서 슬라이스가 가치 있으려면, 이 테스트가 정확히 무엇을 증명해야 하는지 팀이 알고 있어야 합니다.
테스트 슬라이스의 목적은 증명 대상을 좁히는 것입니다
핵심 아이디어는 단순합니다.
- 애플리케이션 컨텍스트를 덜 로드하고
- 하나의 기술 경계에 집중하고
- 더 빠르고 더 명확한 피드백을 받는 것
이 방식은 모든 테스트가 @SpringBootTest로 흘러가면서, 느리기만 하고 설명력은 낮아지는 상황을 막아줍니다.
@WebMvcTest는 HTTP 계약 검증에 강합니다
@WebMvcTest는 다음을 검증할 때 가장 강합니다.
- 요청 매핑
- validation 동작
- 상태 코드
- JSON 응답 구조
- 예외와 응답 변환
- MVC 계층에서의 보안 동작
반대로 repository 동작이나 전체 서비스 통합을 증명하려는 용도는 아닙니다. 슬라이스 밖의 의존성은 mock이나 제한된 테스트 설정으로 의도적으로 채워야 합니다.
@DataJpaTest는 영속성 현실을 검증합니다
@DataJpaTest는 다음을 증명하는 데 유용합니다.
- repository query 정확성
- JPA 매핑
- 생성 SQL 동작
- 페이지네이션과 fetch 동작
- 영속성 계층의 트랜잭션 상호작용
즉, 쿼리 실수와 매핑 surprises, DB 특화 동작은 이 계층에서 먼저 잡는 편이 좋습니다.
다른 슬라이스들도 역할이 있습니다
코드베이스에 따라 다음 같은 슬라이스도 충분히 가치가 있습니다.
@JsonTest: 직렬화/역직렬화 계약 검증@RestClientTest: 외부 HTTP 클라이언트 경계 검증- 그 외 메시징 등 특화 슬라이스
원칙은 같습니다. 증명 대상 하나에 집중한다는 점이 핵심입니다.
슬라이스는 애플리케이션 경계가 분명할수록 잘 작동합니다
프로덕션 코드 경계가 이미 엉켜 있으면 슬라이스 테스트도 불편해집니다.
대표 신호는 다음과 같습니다.
- controller가 비즈니스 로직까지 떠안고 있음
- service가 여러 인프라에 강하게 결합됨
- repository가 도메인 판단까지 갖고 있음
이때 slice test가 mock-heavy하고 읽기 어려워지는 것은 테스트 문제라기보다 설계 신호에 가깝습니다.
@SpringBootTest도 여전히 중요한 역할이 있습니다
full-context 테스트를 완전히 피하는 것이 목표는 아닙니다. @SpringBootTest는 다음을 증명할 때 여전히 유용합니다.
- 실제 cross-layer wiring
- 설정 민감 동작
- 중요한 통합 경로
- 소수의 고가치 end-to-end 애플리케이션 흐름
문제는 @SpringBootTest를 쓴다는 사실이 아니라, 모든 증명 대상을 여기에 몰아넣는 데 있습니다.
흔한 안티패턴
실무에서는 다음 패턴이 자주 테스트 구조를 약하게 만듭니다.
- 모든 것을
@SpringBootTest로 검증 - 슬라이스 테스트에 무관한 의존성을 계속 끌어들임
- 같은 결함 종류를 슬라이스와 full-context에서 중복 검증
- 이 슬라이스가 정확히 무엇을 증명하는지 설명 없이 작성
이런 구조는 스위트를 느리게 만들 뿐, 더 명확하게 만들지 못합니다.
리뷰 체크리스트
슬라이스 사용이 건강한지 보려면 최소한 다음을 물어야 합니다.
- 이 테스트가 증명하는 정확한 경계는 무엇인가
- 이것이 가장 싼 현실적인 증명 계층인가
- 슬라이스 밖 의존성이 의도적으로 통제되고 있는가
- 여기서 full-context 테스트가 정말 새로운 정보를 주는가
- 애플리케이션 설계가 슬라이스를 읽기 쉽게 만들 정도로 분명한가
마무리
Spring test slice는 단순한 속도 해킹이 아니라 책임 분리 도구입니다. 무엇을 증명하는 테스트인지 더 명확할수록, 전체 테스트 전략은 더 건강해집니다.
Continue Reading
다음으로 읽기 좋은 글
REST Assured API 테스트 전략 가이드
REST Assured를 사용해 Java 기반 API를 어떻게 검증할지 정리합니다. 요청/응답 예제보다 계약 검증, 인증 흐름, 테스트 데이터, 통합 테스트 경계에 초점을 맞춘 실무형 가이드입니다.
🧪 TestMock, Stub, Spy 테스트 더블 설계 가이드
Mock, Stub, Spy를 언제 어떤 기준으로 선택해야 하는지 정리합니다. 상태 검증과 상호작용 검증의 차이, 과도한 mocking의 위험, fake와의 선택 기준까지 실무 관점에서 다룹니다.
⚙️ Backend실전에서 버티는 Spring Boot REST API 설계
Spring Boot REST API를 빠르게 만드는 방법이 아니라, 엔드포인트가 늘고 트래픽과 팀 규모가 커져도 경계가 무너지지 않도록 설계하는 기준을 정리합니다.
⚙️ BackendSpring Boot JPA + Hibernate 실전 가이드
엔티티 경계, 연관관계 비용, N+1, DTO 조회, 트랜잭션 설계, 운영상 함정까지 JPA를 실무 기준으로 정리합니다.
다음 탐색