<div id="readability-page-1" class="page"><div><h2 id="bd28">Mockito 어떻게 사용하나요?</h2><h2 id="ef0d">설정</h2><p id="dfed">저희는 Spring Boot를 사용하고 있습니다. Spring Boot에서 Mockito를 설정하는 방법은 아주 간단합니다.</p><figure></figure><p id="765b">spring-boot-starter-test에 Mockito가 이미 포함이 되어있기 때문에 이 설정 하나면 Mockito를 사용할 수 있습니다. spring-boot-starter-test에 어떤 라이브러리들이 포함되어있는 궁금하신 분들은 <a href="https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.testing" rel="noopener nofollow">공식문서</a>를 확인하시면 좋을 거 같네요.</p><h2 id="0f46">기능 훑어보기</h2><p id="7a6b">저희가 주로 사용하는 Mockito의 기능에 대해 설명하면서 어떻게 저희가 사용하는지도 중간중간 덧붙이도록 하겠습니다. Mockito는 기본적으로 Mock 객체 생성, 스텁, 검증 이 세 가지를 지원해줍니다.</p><p id="3be0"><strong>Mock 객체 생성</strong></p><p id="4eeb">Mock 객체를 생성하는 방법은 두가지가 있습니다. mock() 메서드를 이용하거나 @Mock 어노테이션을 사용합니다.</p><figure></figure><p id="4481">저희는 @Mock 과 @MockBean 어노테이션으로 생성하는걸 선호하는데요, 어노테이션을 사용하면 아래와 같은 점이 좋다고 생각합니다.</p><ul><li id="cb4a">반복적인 mock 생성 코드를 줄여준다.</li><li id="3d1e">테스트 클래스의 가독성을 높여준다.</li><li id="9448">필드 이름으로 각각의 mock을 구분하기 때문에, 검증시에 발생하는 에러를 좀 더 읽기 쉽게 만들어준다.</li></ul><p id="047a">그렇다면 @Mock 과 @MockBean의 차이점은 무엇일까요?</p><p id="c460">@Mock은 위에 말씀드린 대로 Mockito.mock() 메서드와 동일합니다. 둘 다 org.mockito.Mock 패키지 안에 있습니다. @MockBean은 org.springframework.boot.test.mock.mockito.MockBean 패키지 안에 있습니다. spring-boot-test에 포함이 되어있기 때문인데요, @SpringBootTest 와 같이 사용되며 Spring application context에 Mock 객체가 추가가 되고 mock객체는 같은 type의 이미 존재하는 Bean들을 대신하게 됩니다. 테스트 할 때 Spring에 의존성이 필요하다면 @MockBean을 사용하면 되고, 의존성 없는 로직을 테스트할 경우에는 @Mock을 사용하면 됩니다.</p><p id="1cae"><strong>스텁 (stubbing)</strong></p><p id="ac1d">스텁은 어떠한 로직을 가지고 있는 것이 아니라 미리 지정한 값을 반환하는 것을 뜻합니다. when().then() 형식으로 when()에는 호출할 조건을 넣고 then()에는 반환하고 싶은 값을 넣으면 됩니다.</p><figure></figure><p id="a269">void 메서드를 stubbing 해야 할 경우도 생길 텐데요 그럼 when(void) 형식이 되어 뭔가 이상하다고 느껴집니다. 그래서 when(Object)와 같은 형태로 void 메소드의 호출을 stubbing 하기 위해서는 다른 방법을 사용해야 합니다. doNothing(), doThrow()를 많이 사용하고 있고 다른 메서드들도 궁금하시다면 <a href="https://javadoc.io/static/org.mockito/mockito-core/3.10.0/org/mockito/Mockito.html#12" rel="noopener nofollow">javadoc</a>을 확인해보세요!</p><figure></figure><p id="9ac7">스텁을 BDD(Behavior Driven Development) 스타일로도 작성할 수 있습니다. 저희도 이런 방법으로 테스트 코드를 작성하고 있는데요, 문제는 위에 예제에서처럼 when().then()을 사용하면 when을 이용한 stubbing이 given의 역할을 하고 있어서 given -when -then 형식에 잘 맞지 않는다는 점이었습니다. 그래서 Mockito는 이러한 문제를 해결하기 위해 BDDMockito 클래스를 제공하고 있고, 스텁을 할 때 사용할 메소드로 BDDMockito.given()를 제공합니다. given()을 사용하면 BDD 스타일로 테스트 코드를 작성할 수 있습니다.</p><figure></figure><p id="7c6d">스텁을 할 때 저희가 자주 쓰는 것 중 하나가 Argument matchers 입니다. Argument matchers는 유연한 stubbing을 할 수 있게 도와줍니다. 지금까지의 예제에서는 when()에 고정된 변수를 넣어 전달했는데 any()를 사용하여 자료형만 맞으면 값을 반환할 수 있습니다. anyInt(), anyFloat(), anyString(), anyBoolean() 등 기본 자료형에 맞는 함수를 제공하고 있고 any()로 특정 클래스를 지정하여 사용할 수 있습니다. Argument matchers를 사용하려면 모든 파라미터는 matcher로 전달되어야 합니다. 그러므로 파라미터가 여러 개를 받아야 하는 상황에서 특정 값과 일치하는 값을 사용하고 싶다면 eq()를 사용해야 합니다. 저희는 주로 특정한 시간을 지정하기 어려울 때 (LocalDate, LocalDateTime 등) 많이 활용하고 있습니다.</p><figure></figure><p id="2bd0"><strong>검증</strong></p><p id="71c5">Mock 객체를 생성하고 스텁한 뒤 어떤 일이 일어났는지 verify()를 통해 검증할 수 있습니다. 기본적으로 호출 횟수를(몇 번 호출됐는지, 최소한 한 번 호출됐는지, 호출되지 않았는지) 확인 할 수 있습니다.</p><ul><li id="c921">times(int) : 몇 번 호출이 되었는지 검증</li><li id="7b99">never() : 호출이 되었는지 검증</li><li id="15bc">atLeast(int) : 적어도 몇 번 호출되었는지 검증</li><li id="24ee">atLeastOnce() : atLeast(1)과 동일</li><li id="3910">atMost(int) : 최대 몇 번 호출 되었는지 검증</li></ul><figure></figure><p id="a4fd">호출 횟수 검증과 함께 timeout() 메서드를 활용하여 타임아웃을 검증 할 수 있습니다. 멀티 스레드 환경에서 테스트할 때 도움이 될 거 같습니다.</p><figure></figure><p id="ffef">Mock들이 순서대로 실행되는지 검증이 가능합니다. 모든 메서드에 대해 하지 않아도 되고, 검증하려고 하는 Mock 객체만 InOrder 객체로 생성하여 순서대로 실행되는지 검증 할 수 있습니다.</p><figure></figure><p id="666a">Mock 객체 간의 상호작용을 검증할 수도 있습니다.</p><ul><li id="c1ac">verifyNoInteractions() : Mock 객체 간의 상호작용이 없는지 검증하며 Naver()와 쓰임새가 같습니다.</li><li id="a867">verifyNoMoreInteractions() : verify 이후 Mock 객체 간의 상호작용이 없는지 검증</li></ul><p id="1e60">(참고) verifyZeroInteractions()는 3.0.1부터 deprecated가 되었기 때문에 verifyNoInteractions()을 사용해야 합니다.</p><figure></figure></div></div>

zigbang - Medium

안녕하세요? 저는 직방홈 파트에서 아파트의 커뮤니티 시설 예약시스템을 담당하고 있는데요, 오늘은 저희의 프로젝트에서 Java mocking framework인 Mockito을 어떻게 사용하고 있는지에 대해 이야기해보려고 합니다.
Mockito는 무엇인가요?
“ Tasty mocking framework for unit tests in Java ”
Mockito 공식 페이지에 있는 소개 글 입니다. 이 한 줄로 모든 게 설명이 되는데요, Mockito는 자바에서 단위테스트를 하기 위해 Mock을 만들어주는 프레임워크입니다. JUnit위에서 동작하며 Mock이 필요한 테스트에 직관적으로 사용할 수 있도록 만들어졌습니다. JetBrains에서 공개한 2020년도 개발자 에코시스템 현황 인포그래픽 자료를 보면 유닛 테스트를 사용하는 개발자의 43%가 Mockito를 사용한다고 합니다. 그리고 (좀 오래된 자료이긴 하지만 ) StackOverflow community에서도 Mockito가 Java를 위한 최고의 mocking framework로 최다 투표를 받기도 했습니다.
Mockito는 아래와 같은 장점들이 있습니다.
깔끔하고 간단한 API를 제공하여서 아름다운 테스트 코드를 작성할 수 있습니다.
Mockito로 작성된 테스트 코드들은 읽기 쉽고 에러가 발생 시 깔끔하게 생성된 에러를 확인할 수 있습니다.
테스팅 툴 뿐만 아닌 모든 Java 라이브러리 Top 10안에 드는 라이브러리 입니다.
Mockito를 왜 사용하게 되었나요?
먼저 배경을 설명해 드리면, 저희 프로젝트에서는 Spring Rest Docs를 사용하여 현재 배포가 되어 동작하고 있는 API와 API 문서를 동일하게 관리하고 있습니다. Spring Rest Docs는 작성한 테스트 코드들이 모두 성공을 해야 문서가 생성되는데, 이러다 보니 모든 컨트롤러에 대해서는 테스트 커버리지가 100%가 되지만 컨트롤러 테스트 코드에서 동작하지 않는 서비스 코드는 테스트가 되지 않아 서비스 코드의 테스트 커버리지가 상대적으로 낮은 문제가 있었습니다. 이런 상황에서 서비스 로직의 테스트 코드가 필요하다는 공감대를 형성하고, 개선하기 위해 앞으로 코드 수정이 있는 서비스의 테스트 코드를 작성하여 테스트 커버리지를 100%로 끌어올리자! 라는 목표를 정하게 되었습니다.
컨트롤러 테스트 -> 통합 테스트
서비스 테스트 -> 단위 테스트
이런 느낌으로 테스트 코드를 작성하고 있는데요, (갈 길이 아직 한참 머네요…..) 작성하다보니 문제가 발생했습니다. 하나의 메서드를 테스트하는데 필요한 정보들이 너무 많았습니다. 예를 들면 헬스장 1개월 이용권을 예약 취소하는 메서드를 테스트한다고 가정해 봅시다.
헬스장 1개월 이용권의 정보
헬스장 1개월을 예약한 이용자의 정보
이용자가 헬스장 1개월을 예약한 정보
이 세 가지 정보가 있어야 예약 취소라는 동작을 할 수 있습니다. 이렇게 데이터간에 의존성을 갖게되니 DB에 테스트를 위한 데이터를 생성하여 넣어두어도 DB에서 데이터를 가져올 때 테스트 환경에 따라 각각 다른 데이터가 조회되는 경우도 생기고, 다른팀과 같이 동작 테스트를 함께 하면 데이터가 변경되어 테스트가 실패하는 경우가 생겼습니다. 이러한 불편함을 개선하기 위하여 일관된 데이터로 테스트할 수 있도록 Mockito를 본격적으로 사용하게 되었습니다!
Mockito 어떻게 사용하나요?
설정
저희는 Spring Boot를 사용하고 있습니다. Spring Boot에서 Mockito를 설정하는 방법은 아주 간단합니다.
https://medium.com/media/9196db72fa3bdd18444c23192b5cee4d/href
spring-boot-starter-test에 Mockito가 이미 포함이 되어있기 때문에 이 설정 하나면 Mockito를 사용할 수 있습니다. spring-boot-starter-test에 어떤 라이브러리들이 포함되어있는 궁금하신 분들은 공식문서를 확인하시면 좋을 거 같네요.
기능 훑어보기
저희가 주로 사용하는 Mockito의 기능에 대해 설명하면서 어떻게 저희가 사용하는지도 중간중간 덧붙이도록 하겠습니다. Mockito는 기본적으로 Mock 객체 생성, 스텁, 검증 이 세 가지를 지원해줍니다.
Mock 객체 생성
Mock 객체를 생성하는 방법은 두가지가 있습니다. mock() 메서드를 이용하거나 @Mock 어노테이션을 사용합니다.
https://medium.com/media/2e573f25110efbe4c3fddcf1ecd0b559/href
저희는 @Mock 과 @MockBean 어노테이션으로 생성하는걸 선호하는데요, 어노테이션을 사용하면 아래와 같은 점이 좋다고 생각합니다.
반복적인 mock 생성 코드를 줄여준다.
테스트 클래스의 가독성을 높여준다.
필드 이름으로 각각의 mock을 구분하기 때문에, 검증시에 발생하는 에러를 좀 더 읽기 쉽게 만들어준다.
그렇다면 @Mock 과 @MockBean의 차이점은 무엇일까요?
@Mock은 위에 말씀드린 대로 Mockito.mock() 메서드와 동일합니다. 둘 다 org.mockito.Mock 패키지 안에 있습니다. @MockBean은 org.springframework.boot.test.mock.mockito.MockBean 패키지 안에 있습니다. spring-boot-test에 포함이 되어있기 때문인데요, @SpringBootTest 와 같이 사용되며 Spring application context에 Mock 객체가 추가가 되고 mock객체는 같은 type의 이미 존재하는 Bean들을 대신하게 됩니다. 테스트 할 때 Spring에 의존성이 필요하다면 @MockBean을 사용하면 되고, 의존성 없는 로직을 테스트할 경우에는 @Mock을 사용하면 됩니다.
스텁 (stubbing)
스텁은 어떠한 로직을 가지고 있는 것이 아니라 미리 지정한 값을 반환하는 것을 뜻합니다. when().then() 형식으로 when()에는 호출할 조건을 넣고 then()에는 반환하고 싶은 값을 넣으면 됩니다.
https://medium.com/media/70e69e9c49f7adc897628e3c8dbe1b71/href
void 메서드를 stubbing 해야 할 경우도 생길 텐데요 그럼 when(void) 형식이 되어 뭔가 이상하다고 느껴집니다. 그래서 when(Object)와 같은 형태로 void 메소드의 호출을 stubbing 하기 위해서는 다른 방법을 사용해야 합니다. doNothing(), doThrow()를 많이 사용하고 있고 다른 메서드들도 궁금하시다면 javadoc을 확인해보세요!
https://medium.com/media/c13179a2f3222b3524b7427cf6d1fd71/href
스텁을 BDD(Behavior Driven Development) 스타일로도 작성할 수 있습니다. 저희도 이런 방법으로 테스트 코드를 작성하고 있는데요, 문제는 위에 예제에서처럼 when().then()을 사용하면 when을 이용한 stubbing이 given의 역할을 하고 있어서 given -when -then 형식에 잘 맞지 않는다는 점이었습니다. 그래서 Mockito는 이러한 문제를 해결하기 위해 BDDMockito 클래스를 제공하고 있고, 스텁을 할 때 사용할 메소드로 BDDMockito.given()를 제공합니다. given()을 사용하면 BDD 스타일로 테스트 코드를 작성할 수 있습니다.
https://medium.com/media/5cb1adbb34b1c3b7f1077d1178e18cea/href
스텁을 할 때 저희가 자주 쓰는 것 중 하나가 Argument matchers 입니다. Argument matchers는 유연한 stubbing을 할 수 있게 도와줍니다. 지금까지의 예제에서는 when()에 고정된 변수를 넣어 전달했는데 any()를 사용하여 자료형만 맞으면 값을 반환할 수 있습니다. anyInt(), anyFloat(), anyString(), anyBoolean() 등 기본 자료형에 맞는 함수를 제공하고 있고 any()로 특정 클래스를 지정하여 사용할 수 있습니다. Argument matchers를 사용하려면 모든 파라미터는 matcher로 전달되어야 합니다. 그러므로 파라미터가 여러 개를 받아야 하는 상황에서 특정 값과 일치하는 값을 사용하고 싶다면 eq()를 사용해야 합니다. 저희는 주로 특정한 시간을 지정하기 어려울 때 (LocalDate, LocalDateTime 등) 많이 활용하고 있습니다.
https://medium.com/media/6ddc2642dc856d6109bed907ef26f859/href
검증
Mock 객체를 생성하고 스텁한 뒤 어떤 일이 일어났는지 verify()를 통해 검증할 수 있습니다. 기본적으로 호출 횟수를(몇 번 호출됐는지, 최소한 한 번 호출됐는지, 호출되지 않았는지) 확인 할 수 있습니다.
times(int) : 몇 번 호출이 되었는지 검증
never() : 호출이 되었는지 검증
atLeast(int) : 적어도 몇 번 호출되었는지 검증
atLeastOnce() : atLeast(1)과 동일
atMost(int) : 최대 몇 번 호출 되었는지 검증
https://medium.com/media/a5c7b13291de84249abe94bf7518a8ca/href
호출 횟수 검증과 함께 timeout() 메서드를 활용하여 타임아웃을 검증 할 수 있습니다. 멀티 스레드 환경에서 테스트할 때 도움이 될 거 같습니다.
https://medium.com/media/f92303afcfdecd1c0802deee33ce7dcd/href
Mock들이 순서대로 실행되는지 검증이 가능합니다. 모든 메서드에 대해 하지 않아도 되고, 검증하려고 하는 Mock 객체만 InOrder 객체로 생성하여 순서대로 실행되는지 검증 할 수 있습니다.
https://medium.com/media/0060c99e3c3f277a7193bda16226bbc3/href
Mock 객체 간의 상호작용을 검증할 수도 있습니다.
verifyNoInteractions() : Mock 객체 간의 상호작용이 없는지 검증하며 Naver()와 쓰임새가 같습니다.
verifyNoMoreInteractions() : verify 이후 Mock 객체 간의 상호작용이 없는지 검증
(참고) verifyZeroInteractions()는 3.0.1부터 deprecated가 되었기 때문에 verifyNoInteractions()을 사용해야 합니다.
https://medium.com/media/ad64e7affe906a8862179be41e80632e/href
마치며
주요 Mockito의 기능에 대해 훑어보면서 어떻게 쓰고 있는지 중간중간 이야기를 드렸는데 어떠셨는지 모르겠네요. Mockito를 사용하면서 전보다 테스트 코드를 편하게 작성할 수 있고, 작성 시간도 줄어들어서 만족하며 사용하고 있습니다. 글을 작성하면서 제대로 알지 못했던 기능들도 알게 되어서 테스트 코드를 좀 더 개선하고 싶네요! 긴 글 읽어주셔서 감사합니다.
참고자료
https://site.mockito.org/
https://github.com/mockito/mockito/wiki/Mockito-features-in-Korean
https://javadoc.io/static/org.mockito/mockito-core/3.10.0/org/mockito/Mockito.html
https://www.baeldung.com/mockito-series
우리의 테스트에 Mockito 한잔 was originally published in 직방 기술 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

우리의 테스트에 Mockito 한잔

댓글