Mockito를 이용한 단위 테스트 작성

 이번 프로젝트를 진행하면서 처음으로 테스트 코드를 작성해보았다.
그 전에는 인강 강사님이 치는 것만 따라쳐봤는데, 실제 프로젝트에 적용하려니 스프링부트가 뜨는 데 너무 오래 걸렸다🥲
정확한 시간은 재보지 않았지만 대략 3~5초의 시간이 걸렸고, 이에 대한 해결방법을 찾다가 Mockito라는 걸 사용해보게 되었다.
 

1. Mockito란?

Mockito는 Mock, 쉽게 말해 가짜 객체를 지원해주는 라이브러리이다. 가짜 객체를 사용하면 단위 테스트가 편해진다.
 
기존의 통합 테스트는 모든 빈을 띄우기 때문에 실행하는 데 시간이 오래 걸린다. 또한 다른 클래스의 정상 동작 여부에 따라 테스트 결과가 바뀐다는 문제점이 있었다.  Service의 createTag()가 정상 동작하는 걸 확인하고 싶어도, Repository에 문제가 있으면 createTagTest() 메서드 자체가 실패하는 식이다.
 
개발자가 직접 가짜 객체 클래스를 생성하여 테스트하는 방법도 있지만, 테스트용 가짜 객체 클래스를 관리하는 건 번거롭고 귀찮다.
아마 귀찮음을 이기지 못한 누군가가 이렇게 좋은걸 만들어준게 아닐까~?🤷‍♀️ 
 
이러한 이유로 Mockito를 이용해 가짜 객체를 생성하여, 단위 테스트에 도전해보기로 했다🔥

 

2. 컨트롤러 단위 테스트 

@RestController
@RequestMapping("/api/v1/tags")
@RequiredArgsConstructor
public class TagController {

    private final Long TEMP_USER_ID = 1L;

    private final TagService tagService;

    @PostMapping
    public ResponseEntity<Void> createTag(@RequestBody @Valid final TagCreateRequest request) {
        tagService.save(TEMP_USER_ID, request);

        return ResponseEntity.noContent().build();
    }
}

 

"/api/v1/tags"라는 Path로 POST 요청을 보내, 응답코드 204가 제대로 오는지를 테스트해보자.

 

(1) @WebMvcTest를 통해 웹 계층 테스트 준비

@WebMvcTest(TagController.class)
class TagControllerTest {
	...
}

 

- @WebMvcTest: SpringMVC 컴포넌트에만 집중한 테스트를 가능하게 해 주는 애노테이션이다.

 

@WebMvcTest를 사용하면, 애플리케이션의 전체 컨텍스트가 아닌 TagController와 관련된 웹 계층 빈들만 로드할 수 있다. (따라서 Controller, Filter, JsonComponent 등은 로드되지만, Service, Repository 등은 로드되지 않는다.)

참고로 @WebMvcTest가 붙은 테스트는 MockMvc와 스프링 시큐리티가 자동으로 설정되어 있다.

 

(2) 필요한 객체 생성 및 주입하기

@WebMvcTest(TagController.class)
class TagControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @Autowired
    private ObjectMapper objectMapper;

    @MockBean
    private TagService tagService;
}

 

- MockMvc: 서버 사이드 Spring MVC 테스트를 지원하는 클래스로, HTTP 요청 및 응답의 시뮬레이션을 담당한다.

- ObjectMapper: 객체 ⇔ JSON 사이의 변환을 담당한다. 여기서는 RequestDTO를 JSON으로 변환하여 HTTP Request Body에 넣기 위해 사용하였다.

- @MockBean: 가짜 빈 객체를 생성해준다. 여기서는 @WebMvcTest에 의해 스프링 컨텍스트의 일부가 로드되었으므로, @Mock 대신  @MockBean을 사용해주어야 한다.

 

(3) 테스트 메서드 작성

@Test
void 태그_등록_요청을_성공한다() throws Exception {
    // given
    final TagCreateRequest tagCreateRequest = new TagCreateRequest("tag_Name");


    // when
    final ResultActions resultActions = mockMvc.perform(post("/api/v1/tags")
                    .contentType(MediaType.APPLICATION_JSON)
                    .content(objectMapper.writeValueAsString(tagCreateRequest)));

    // then
    resultActions.andExpect(status().isNoContent());
}

 

먼저 요청에 이용할 RequestDTO를 생성한 다음, MockMvc.perform()을 이용해 HTTP Request를 보낸다.

 

perform()은 HTTP 요청을 시뮬레이트하는 데 사용되는 메서드로, 체이닝을 통해 GET, POST 등의 HTTP Method와 요청 헤더, 쿠키 값을 지정할 수 있다. (Content-Type 헤더가 application/json임에 주의하자.)

ObjectMapper를 이용해 RequestDTO 객체를 JSON으로 변환하여 Request Body에 담아 요청을 보내면, 그에 대한 응답은 ResultAction에 담긴다.

 

ResultAction은 HTTP 응답을 검증하는데 사용되는 클래스로, 아래와 같은 메서드를 지원한다.

- andExpect(): 응답 코드, 응답 바디에 담긴 내용 등을 검증할 수 있다. 만약 기대값과 실제 결과값이 다를 경우 예외가 발생한다.

- andDo(): 응답 내용을 출력하거나 로그에 기록할 때 사용한다.

- andReturn(): 응답 결과를 MvcResult 라는 객체에 담아 반환한다.

 

여기서는 응답코드 204를 반환을 기대하도록 설정했다.

 

(4) 실행 결과 확인

 

---

3. 서비스 단위 테스트

@Service
@RequiredArgsConstructor
@Transactional
public class TagService {

    private final TagRepository tagRepository;

    private final UserRepository userRepository;

    public Long save(final Long userId, final TagCreateRequest tagCreateRequest) {
        final User user = userRepository.findById(userId)
                .orElseThrow(() -> new BadRequestException(NOT_FOUND_USER));

        if (checkDuplicateTagName(user.getId(), tagCreateRequest.getName())) {
            throw new BadRequestException(DUPLICATED_TAG_NAME);
        }

        final Tag createdTag = Tag.builder()
                .name(tagCreateRequest.getName())
                .user(user)
                .createdAt(LocalDateTime.now())
                .build();

        Tag tag = tagRepository.save(createdTag);

        return tag.getId();
    }
}

 
이제 TagService에 대한 테스트 코드를 작성해 보자. TagService가 save()함수를 호출했을 때, 저장된 태그의 id를 제대로 반환하는지 확인해보려고 한다.
TagService는 스프링으로부터 TagRepository와 UserRepository를 주입받고 있다. 

(1) Junit과 Mockito 결합하기

@ExtendWith(MockitoExtension.class)
class TagServiceTest {
	...
}

 
먼저 Mockito와 Junit을 함께 사용하기 위해서 테스트 클래스 위에 @ExtendWith(MockitoExtension.class) 애노테이션을 달아준다.
 

(2) 가짜 객체 생성 및 주입하기

@ExtendWith(MockitoExtension.class)
class TagServiceTest {

    @InjectMocks
    private TagService tagService;

    @Mock
    private TagRepository tagRepository;

    @Mock
    private UserRepository userRepository;
    
}

 
이렇게 테스트에 필요한 객체들을 선언해준다.
 
- @InjectMocks: 테스트할 객체가 가짜 객체를 주입받을 수 있도록 해준다. 여기서는 tagService에 붙여주었다.
- @Mock: 가짜 객체를 생성해주는 애노테이션이다. 이제 tagService는 가짜 tagRepository와 가짜 userRepository를 주입받을 수 있다.
 
 

(3) 테스트 메서드 작성

tagService가 실제로 save() 메서드를 호출받았을 때, 저장한 태그의 id를 잘 리턴하는지를 테스트해보자.
 

static Tag COMPANY_TAG = Tag.builder()
                	.id(1L)
                	.name("회사")
                	.createdAt(LocalDateTime.now())
               		.build();
                    
static User USER_KIM = User.builder()
                	.id(2L)
                	.email("siltarae@nn.com")
                	.createdAt(LocalDateTime.now())
                	.nickname("Kim")
                	.socialType(SocialType.GOOGLE)
                	.build();

 
먼저 테스트용 데이터를 준비한다.
여기서는 회사 태그와, 이름이 Kim인 사용자를 준비했다.
 

@Test
void 태그_생성_후_tagId를_반환한다() {
    // given
    final TagCreateRequest tagCreateRequest = new TagCreateRequest(COMPANY_TAG.getName());
    given(userRepository.findById(2L))
            .willReturn(Optional.ofNullable(USER_KIM));
    given(tagRepository.save(any(Tag.class)))
            .willReturn(COMPANY_TAG);

    // when
    final Long actualId = tagService.save(2L, tagCreateRequest);

    // then
    assertThat(actualId).isEqualTo(1L);
}

 
이제 stubbing을 할 차례이다. stubbing이란, 가짜 객체의 특정 행동을 지정하는 것인데, 테스트 환경을 확실히 제어하기 위해 사용한다.
 
만약 userRepository가 엉뚱하게 행동하면? 위 테스트는 실패한다. 그래서 미리 가짜 객체한테 '너 이 메서드 호출되면 이렇게 행동해야해. 알았지?' 라고 일러두는 것이다. 여기서는 BDD 구조에 맞추어 작성할 수 있도록 BDDMockito를 사용했다. 
 
given()은 어떤 객체가 어떤 명령을 받았을 때를 지정한다. 위에서 userRepository는 id=2인 User를 찾으라는 명령을 받았을 때를 지정받았다.
그리고 willReturn()을 통해 해당 상황에서 어떤 값을 반환할지를 설정할 수 있다. userRepository는 해당 상황에서 항상 USER_KIM을 반환한다.

💡 BDDMockto란?
Mockito를 BDD 구조에 맞춰 사용할 수 있도록 확장한 것. 기능의 차이는 없지만, 가독성이 향상된 메서드명을 제공한다.

 
 
when 절에서는 실제 tagService의 save() 메서드를 호출한 뒤, 결과로 반환된 값을 받아온다.
마지막으로 then 절에서 반환값이 1이 맞는지를 체크하면 테스트가 끝난다.

(4) 실행 결과 확인

 

---

4. 참고자료

Mockito Tutorial
https://mangkyu.tistory.com/145 

WebMvcTest docs