둘 다 SpringBoot에서 JUnit을 사용하여 테스트코드를 작성할 때 대표적으로 쓰인다.
🟠 @SpringBootTest
- 프로젝트 내 스프링 빈을 모두 등록하여 테스트에 필요한 의존성을 추가한다.
- 실제 운영 환경에서 사용될 클래스들을 통합하여 테스트할 수 있다.
- 단위 테스트 같은 기능 검증이 아니라, Spring Framework에서 전체적으로 Flow가 제대로 동작하는지 검증한다.
장점
애플리케이션의 설정이나 모든 빈을 로드하므로 운영환경과 가장 유사하게 테스트 할 수 있다.
Service 메서드의 스펙이 변경되어도 Mocking값을 수정하지 않아도 되므로 변경에 자유롭다.
단점
테스트 단위가 크므로 디버깅이 까다롭다.
로드할 것이 많아 시간이 오래 걸린다.
🟠 @WebMvcTest
-
슬라이스 테스트.
-
Controller가 예상대로 동작하는지 테스트하는 것.
-
Web Layer만 로드하므로 빠르고 가볍게 테스트할 수 있다.
-
@WebMvcTest() 의 프로퍼티로 테스트를 하려는 컨트롤러 클래스를 넣어준다.
@WebMvcTest(MemberController.class) -
이 어노테이션은 @Controller같은 웹과 관련된 빈만 주입되며 @Service와 같은 일반적인 @Component는 생성되지 않으므로 해당 컨트롤러를 생성하는 데 필요한 다른 빈을 정의하지 못해 NoSuchBeanDefinitionException오류가 발생할 수 있다.
이런 경우에는 @MockBean을 사용해 필요한 의존성을 채워줘야 한다. -
@WebMvcTest 어노테이션을 사용하면 아래 항목들만 스캔한다.
(@Controller, @ControllerAdvice, @JsonComponent, @Convert, @GenericConverter, Filter, WebMvcConfigurer, HandlerMethodArgumentResolver) -
Security, Filter, Interceptor, request/response Handling, Controller의 항목들만 스캔하도록 제한하며, @Component는 스캔 대상에서 제외된다.
장점
WebApplication과 관련된 Bean 들만 등록하기 때문에 @SpringBootTest보다 빠르다.
통합테스트를 하기 어려운 경우 개별적으로 테스트가 가능하다.
(ex. 결제 모듈 API사용에서 특정 조건에 따라 실패하는 경우를 Mock을 통해 가짜 객체를 만들어 테스트 가능)
단점
Mock을 기반으로 테스트하므로 실제 환경에서는 예상 밖의 동작오류가 발생할 수 있다.
Mocking 메서드의 변경이 일어나면 수정해야 한다.
참고
https://astrid-dm.tistory.com/536
https://wiselog.tistory.com/171
https://jaehoney.tistory.com/213
