Test Double

🧪 1. Mock / Stub / Mockito / @MockBean 정리

---

1. 왜 테스트 더블(Test Double)이 필요한가

실제 코드를 그대로 테스트에 사용하면 이런 문제가 생긴다.

• DB에 실제로 쿼리 날림
• 외부 API 호출(결제, 문자, 카카오, S3 등)
• 네트워크 의존
• 테스트 데이터 세팅이 복잡해짐
• 테스트가 느리고, 실패 원인이 코드인지 환경인지 애매해짐

그래서 테스트에서는 “진짜 객체 대신 사용하는 가짜 객체”를 쓰는데, 이것들을 통틀어 테스트 더블(Test Double) 이라고 한다.

대표적인 종류:

• Stub
• Mock
• Fake
• Spy

이 중에서 Spring + Mockito 환경에서 가장 자주 보는 건 Stub, Mock 이다.

---

2. Stub: 가장 단순한 테스트 더블

2.1 Stub의 정의

“미리 정해둔 반환값만 돌려주는 단순 가짜 객체”

특징:

• 내부 비즈니스 로직 없음
• 호출 횟수, 파라미터 검증 불가
• 오직 “특정 입력 → 특정 출력”만 보장하는 단순 구현

2.2 예시 코드

public interface UserService {
    User findById(Long id);
}

public class StubUserService implements UserService {

    @Override
    public User findById(Long id) {
        // 항상 같은 값 반환 (테스트용)
        return new User("pong", 27);
    }
}

테스트에서:

UserService userService = new StubUserService();
User user = userService.findById(1L);
// 항상 "pong" 반환

2.3 언제 쓰는가

• “이 메서드는 언제나 이 값을 반환한다고 가정하고 테스트하고 싶다”
• 호출 횟수, 파라미터 같은 건 신경 안 쓸 때
• 아주 단순한 단위 테스트, TDD 연습용

실무에서 Stub 클래스를 직접 만드는 경우는 점점 줄어드는 추세다.
대부분 Mock을 사용하면서 Stub 기능까지 함께 쓰기 때문이다.

---

3. Mock: Stub + 행동 검증까지 가능한 테스트 더블

3.1 Mock의 정의

“가짜 객체인데,

• 어떤 값을 반환하게 만들 수도 있고
• 어떻게 호출되었는지(횟수, 파라미터)를 검증할 수 있는 객체”

Mock은 Stub보다 훨씬 강력하다.

3.2 Mockito를 사용한 Mock 예제

@ExtendWith(MockitoExtension.class)
class UserServiceTest {

    @Mock
    private UserRepository userRepository;  // 가짜 Repo

    @InjectMocks
    private UserServiceImpl userService;    // 테스트할 실제 Service

    @Test
    void findById_정상조회() {
        // given
        User user = new User("pong", 27);
        when(userRepository.findById(1L))
                .thenReturn(Optional.of(user));  // Stub 역할

        // when
        User result = userService.findById(1L);

        // then
        assertThat(result.getName()).isEqualTo("pong");
        verify(userRepository, times(1)).findById(1L); // Mock의 행동 검증
    }
}

여기서 중요한 포인트:

• when(...).thenReturn(...)
  → Stub 역할 (입력 → 출력 고정)
• verify(..., times(1))
  → Mock 고유 기능 (호출 횟수 검증)

3.3 Mock의 장점

• 반환값을 자유롭게 세팅 가능
• 예외를 던지도록 설정 가능 (thenThrow)
• 메서드 호출 횟수 검증 가능
• 어떤 파라미터로 호출됐는지 검증 가능 (verify(mock).save(argThat(...)))
• “이 메서드는 호출되면 안 된다”도 검증 가능(never())

Stub으로는 행동 검증이 불가능하지만,
Mock은 행동까지 검증할 수 있기 때문에 훨씬 유연하다.

---

4. Mockito: Mock을 만들어주는 라이브러리

4.1 Mockito란?

“Java에서 Mock 객체를 만들고,
그 동작을 설정하고,
호출 여부를 검증할 수 있게 해주는 라이브러리”

Spring Boot 테스트에서 거의 기본처럼 사용한다.

주요 기능:

• @Mock, @InjectMocks 지원
• when(...).thenReturn(...), thenThrow(...) 등 Stub 설정
• verify(...) 로 호출 여부 / 횟수 / 파라미터 검증
• spy로 실제 객체 + 일부만 모킹도 가능

---

5. @MockBean: Spring Test + Mockito 연동

5.1 @MockBean 정의

“Spring ApplicationContext에 있는 Bean을 Mockito Mock 객체로 교체해주는 Spring Boot 테스트용 어노테이션”

예:

@WebMvcTest(UserController.class)
class UserControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @MockBean
    private UserService userService; // 여기!

    @Test
    void getUser() throws Exception {
        when(userService.findById(1L))
                .thenReturn(new User("pong", 27));

        mockMvc.perform(get("/users/1"))
                .andExpect(status().isOk())
                .andExpect(jsonPath("$.name").value("pong"));
    }
}

이 코드에서:

• 원래라면 Spring이 UserService 구현체를 Bean으로 등록해야 함
• 하지만 @WebMvcTest는 Service를 로드하지 않음
• @MockBean이 해당 타입의 빈을 Mockito Mock으로 등록
• 컨트롤러에는 진짜 서비스 대신 이 Mock이 주입됨

5.2 @MockBean이 필요한 이유

• @WebMvcTest는 Controller + MVC 관련 Bean만 로드한다.
• 그 외 Service, Repository는 로딩하지 않기 때문에 null이 됨.
• 그 상태로 테스트하면 NullPointerException 발생.
• 그래서 컨트롤러가 의존하는 서비스들을 @MockBean으로 채워 넣는 것이 필수.

5.3 @Mock vs @MockBean 차이

어노테이션	어디에 쓰는가	역할
@Mock	순수 JUnit + Mockito 테스트 (Spring context 없음)	단순한 Mockito mock 생성
@MockBean	Spring Boot 테스트 (Spring context 사용)	해당 타입의 Spring Bean을 Mockito mock으로 교체

---

6. Mock이 Stub보다 “더 좋다?”에 대한 정리

• Stub와 Mock은 우열 관계가 아니라 역할이 다르다.
• 실제로는 Mock이 Stub 기능을 포함한다.

정리하면:

• Stub

  • 정해진 값만 반환
  • 행동 검증 불가
  • 아주 단순한 테스트에 적합

• Mock

  • Stub 기능 포함 + 행동 검증
  • 복잡한 케이스, 예외, 호출 횟수 검증 등 실무 테스트에 적합
  • Spring + Mockito 환경에서는 Mock이 사실상 표준

현대 Spring 환경에서는 직접 Stub 클래스를 만드는 것보다, Mockito Mock을 써서 Stub+Mock 기능을 같이 사용하는 패턴이 압도적으로 많다.

---

🧵 요약

• 테스트 더블은 “실제 객체 대신 테스트에 사용하는 가짜 객체”
• Stub: 결과만 고정, 행동 검증 불가
• Mock: Stub + 행동 검증까지 가능
• Mockito: Mock을 만들어주고 검증까지 도와주는 라이브러리
• @MockBean: Spring Bean을 Mockito Mock으로 바꿔치기하는 Spring Boot 전용 어노테이션
• 실무에서는 대부분 Stub 대신 Mock(@MockBean 포함)을 사용한다.

---

---

🛰️ 2. MockMvc / @WebMvcTest로 컨트롤러 테스트 제대로 이해하기

---

1. 컨트롤러 테스트 전략 전체 그림

Spring에서 컨트롤러를 테스트하는 방법은 크게 3가지 레벨이 있다.

1. 단위 테스트 수준

   • 컨트롤러 객체를 new 해서 직접 호출
   • Spring MVC, 필터, Validation, Security 등은 안 탐

2. 웹 레이어 테스트

   • MockMvc + @WebMvcTest
   • DispatcherServlet, 필터, 인터셉터, ArgumentResolver, Validation, Security 등 MVC 레이어 전체 흐름을 실제처럼 실행
   • 서버(WAS)는 띄우지 않음

3. 통합 테스트

   • @SpringBootTest + TestRestTemplate 또는 WebTestClient
   • 실제 서버 포트까지 띄워서 호출
   • DB 포함 전체 스택 테스트

여기서 우리가 보고 있는 건 2번: MockMvc + @WebMvcTest 조합이다.

---

2. MockMvc: WAS 없는 Spring MVC 테스트 도구

2.1 정의

“Spring MVC의 DispatcherServlet을 실제로 동작시키면서,
HTTP 요청/응답 흐름을 WAS 없이 테스트할 수 있게 해주는 도구”

즉:

• 실제로 get("/path"), post("/path") 같은 요청을 보낼 수 있고
• 필터, 인터셉터, 컨트롤러, 예외 처리, 응답 변환까지 모두 통과한다.
• 단지 Tomcat 같은 서버는 띄우지 않는다.

2.2 대표 사용 예시

@WebMvcTest(UserController.class)
class UserControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @MockBean
    private UserService userService;

    @Test
    void 유저_단건_조회_API() throws Exception {
        // given
        when(userService.findById(1L))
                .thenReturn(new User("pong", 27));

        // when & then
        mockMvc.perform(get("/api/users/{id}", 1L)
                        .accept(MediaType.APPLICATION_JSON))
                .andExpect(status().isOk())
                .andExpect(jsonPath("$.name").value("pong"))
                .andExpect(jsonPath("$.age").value(27));
    }
}

여기서 MockMvc는 다음을 수행한다:

1. GET /api/users/1 요청 생성
2. DispatcherServlet 실행
3. HandlerMapping → UserController 매핑
4. HandlerAdapter → 메서드 호출, 파라미터 바인딩
5. Service 호출 (여기선 @MockBean으로 대체된 mockService)
6. 반환 객체를 JSON으로 변환
7. HTTP 응답으로 포장
8. status, jsonPath로 응답 검증

---

3. @WebMvcTest: “웹 레이어만 로드하는” 테스트 설정

3.1 정의

“Controller와 MVC 관련 구성 요소만 로딩해서 웹 레이어를 얇게 테스트하도록 만든 Spring Boot 테스트용 애노테이션”

예:

@WebMvcTest(UserController.class)
class UserControllerTest {
    ...
}

3.2 로드되는 Bean / 로드되지 않는 Bean

로드됨:

• @Controller, @RestController
• @ControllerAdvice (전역 예외 처리 등)
• Spring MVC 설정 (WebMvcConfigurer 등 일부)
• ObjectMapper (JSON 직렬화/역직렬화)
• MessageConverter들
• Spring Security 관련 필터/설정 (Security 사용 시)

로드되지 않음:

• @Service
• @Repository
• 대부분의 @Component
• DB 관련 설정, DataSource, JPA, MyBatis 등

그래서 @WebMvcTest는 오직 “웹 레이어 테스트” 용이라고 보면 된다.

---

4. @WebMvcTest + @MockBean + MockMvc 조합 흐름

전체 그림은 이렇게 된다:

@WebMvcTest(UserController.class)
   ↓
Spring이 UserController, MVC 관련 빈만 로드
   ↓
@MockBean UserService
   ↓
실제 UserService 빈 대신 Mockito Mock 객체를 Spring Bean으로 등록
   ↓
@Autowired MockMvc
   ↓
MockMvc로 HTTP 요청 시뮬레이션
   ↓
DispatcherServlet → Filter → Interceptor → UserController → Mock(UserService)
   ↓
응답(JSON) 검증

이 구조 덕분에:

• 서버를 띄우지 않고도 (WAS 없음)
• 컨트롤러 + 필터 + 시큐리티 + Validation까지
• 실제 API처럼 테스트할 수 있다.

---

5. 다른 테스트 방식들과 비교

5.1 @WebMvcTest + MockMvc (웹 레이어 테스트)

• 목적: 컨트롤러 + 웹 레이어 검증

• 장점:

  • 매우 빠름
  • MVC 흐름, 시큐리티, Validation, 응답 형식까지 확인 가능

• 단점:

  • Service/Repository는 Mock으로 대체해야 함
  • DB에 대한 통합 검증은 불가능

5.2 @SpringBootTest + MockMvc (애플리케이션 전체 + MockMvc)

@SpringBootTest
@AutoConfigureMockMvc
class UserControllerIntegrationTest {

    @Autowired
    private MockMvc mockMvc;

    // 진짜 UserService, UserRepository, DB까지 전부 로드
}

• 목적: 조금 더 무거운 통합 테스트

• 장점:

  • 전체 Bean 로드 → 실제 Service, Repository, DB까지 사용 가능

• 단점:

  • 느리다
  • 테스트 컨텍스트가 무거움

5.3 @SpringBootTest + TestRestTemplate / WebTestClient (완전 통합 테스트)

• 실제 서버 포트에 HTTP로 요청
• 인프라 환경까지 최대한 실제와 가깝게 검증
• 가장 느리고, 셋업이 무겁지만, 신뢰도는 가장 높음

---

6. 언제 어떤 방식을 선택해야 하는가

상황	추천 방식
컨트롤러의 Request/Response, Validation, Security, 예외 처리만 검증하고 싶다	@WebMvcTest + MockMvc + @MockBean
서비스 로직 + DB까지 실제로 동작시키며 API를 검증하고 싶다	@SpringBootTest + MockMvc
실제 운영과 거의 동일한 환경에서 E2E 레벨 테스트를 하고 싶다	@SpringBootTest + TestRestTemplate/WebTestClient

현실적인 패턴:

• 컨트롤러 테스트: @WebMvcTest + MockMvc + @MockBean
• 서비스/리포지토리 + DB 통합 테스트: @SpringBootTest (또는 slice 테스트)
• 최종적으로 몇 개의 핵심 시나리오만 E2E 테스트 추가

---

7. 간단한 실전 템플릿

@WebMvcTest(UserController.class)
class UserControllerTest {

    @Autowired
    MockMvc mockMvc;

    @MockBean
    UserService userService;

    @Test
    void getUser_정상_응답() throws Exception {
        // given
        when(userService.findById(1L))
                .thenReturn(new User("pong", 27));

        // when & then
        mockMvc.perform(get("/api/users/{id}", 1L)
                        .accept(MediaType.APPLICATION_JSON))
                .andExpect(status().isOk())
                .andExpect(jsonPath("$.name").value("pong"))
                .andExpect(jsonPath("$.age").value(27));

        verify(userService, times(1)).findById(1L);
    }
}

이 한 파일에 지금까지 정리한 개념이 전부 들어 있다:

• @WebMvcTest → 웹 레이어만 로드
• MockMvc → HTTP 요청/응답 테스트
• @MockBean → Service를 Mockito Mock으로 교체
• when(...).thenReturn(...) → Stub 기능
• verify(...) → Mock 행동 검증

---

🧵 요약

• MockMvc: DispatcherServlet을 실제로 돌리면서, WAS 없이 MVC 흐름을 테스트하는 도구
• @WebMvcTest: Controller + MVC 관련 Bean만 로드하는 “웹 레이어 슬라이스 테스트”
• @MockBean: Controller가 의존하는 Service/Repository를 Mock으로 교체
• @WebMvcTest + MockMvc + @MockBean 조합으로
  “가볍고 빠르게, 하지만 실제 MVC 흐름에 가깝게” 컨트롤러를 테스트할 수 있다.