Chapter - 슬라이스 테스트(Slice Test)
이번 시간에는 Spring에서 의미하는 슬라이스 테스트(Slice Testing)가 무엇인지 알아보고, Spring MVC 기반의 계층별 테스트를 진행하는 방법을 살펴보도록 하겠습니다.
핵심 포인트
- 슬라이스 테스트(Slice Testing)의 의미를 이해할 수 있다.
- Spring에서 지원하는 테스팅 기능을 이용해서 API 계층의 Controller를 테스트할 수 있다.
- Spring에서 지원하는 테스팅 기능을 이용해서 데이터 액세스 계층의 Repository를 테스트할 수 있다.
[기본] API 계층 테스트
슬라이스 테스트란?
여러분들이 학습을 위해서 만들어보고 있는 샘플 애플리케이션은 여러 개의 계층으로 나누어져 있습니다.
단위 테스트의 경우 일반적으로 특정 모듈이나 계층, 기술에 의존적이지 않도록 작성하는 것이 좋습니다.
그런데 단위 테스트 만으로는 애플리케이션의 모든 기능이 정상적으로 동작한다라고 백 퍼센트 보장되지는 않습니다.
하나의 애플리케이션은 계층별로 역할이 있고, 계층별로 서로 연동되기 때문에 각각의 계층 별로 잘 동작하는지 테스트를 진행한 후에 마지막으로 통합 테스트를 통해서 계층 간의 연동에 문제가 없는지 확인해야 비로소 개발자의 테스트 작업이 마무리되는 것이라고 할 수 있습니다.
이처럼 개발자가 각 계층에 구현해 놓은 기능들이 잘 동작하는지 특정 계층만 잘라서(Slice) 테스트하는 것을 슬라이스 테스트(Slice Test)라고 합니다.
개발자가 통합 테스트까지 작성하면 정말 바람직하겠지만 현실에서는 일정 상의 이유 등으로 인해 통합 테스트는 QA 부서에서 진행하는 기능 테스트로 대체되는 경우가 많습니다.
그리고 통합 테스트는 아니지만 QA 부서에서 본격적으로 전체적인 기능 테스트를 진행하기 전에 애플리케이션의 특정 수정 사항으로 인해 영향을 받을 수 있는 범위에 한해서 제한된 테스트를 진행하기도 합니다. 테스트 세계에서는 이를 스모크 테스트(Smoke Test)라고 부릅니다.
스모크 테스트(Smoke Test)에 대해서 더 알아보고 싶다면 아래 [심화 학습]을 참고하세요.
API 계층 테스트
API 계층의 테스트 대상은 대부분 클라이언트의 요청을 받아들이는 핸들러인 Controller입니다.
Spring에서는 Controller를 테스트하기 위한 편리한 방법들을 제공합니다.
지금부터 Spring에서 지원하는 기능들을 이용해 우리가 작성한 Controller들을 테스트하는 방법을 알아보도록 하겠습니다.
Controller 테스트를 위한 테스트 클래스 구조
Spring Boot에서는 API 계층의 Controller를 테스트하기 위한 다양한 애너테이션을 제공하는데, 하나의 Controller 클래스를 테스트하기 위한 테스트 클래스의 기본 구조는 [코드 3-191]과 같습니다.
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.web.servlet.MockMvc;
@SpringBootTest // (1)
@AutoConfigureMockMvc // (2)
public class ControllerTestDefaultStructure {
// (3)
@Autowired
private MockMvc mockMvc;
// (4)
@Test
public void postMemberTest() {
// given (5) 테스트용 request body 생성
// when (6) MockMvc 객체로 테스트 대상 Controller 호출
// then (7) Controller 핸들러 메서드에서 응답으로 수신한 HTTP Status 및 response body 검증
}
}
[코드 3-191] Controller 테스트용 테스트 클래스 기본 구조
- (1)의 @SpringBootTest 애너테이션은 Spring Boot 기반의 애플리케이션을 테스트하기 위한 Application Context를 생성합니다.
- 여러분들이 잘 알다시피 Application Context에는 애플리케이션에 필요한 Bean 객체들이 등록되어 있습니다.
- (2)의 @AutoConfigureMockMvc 애너테이션은 Controller 테스트를 위한 애플리케이션의 자동 구성 작업을 해줍니다.(3)의 MockMvc 같은 기능을 사용하기 위해서는 @AutoConfigureMockMvc 애너테이션을 반드시 추가해 주어야 합니다.
- 여러분들이 Spring Boot의 자동 구성을 통해 애플리케이션의 설정을 손쉽게 사용하듯이 @AutoConfigureMockMvc 애너테이션을 추가함으로써 테스트에 필요한 애플리케이션의 구성이 자동으로 진행됩니다.
- (3)에서 DI로 주입받은 MockMvc는 Tomcat 같은 서버를 실행하지 않고 Spring 기반 애플리케이션의 Controller를 테스트할 수 있는 완벽한 환경을 지원해 주는 일종의 Spring MVC 테스트 프레임워크입니다.
- MockMvc 객체를 통해 우리가 작성한 Controller를 호출해서 손쉽게 Controller에 대한 테스트를 진행할 수 있습니다.
- (1), (2), (3)을 통해 Controller를 테스트할 준비가 되었습니다.
- 이제 (4)와 같이 테스트하고자 하는 Controller 핸들러 메서드의 테스트 케이스를 작성하면 됩니다.
- 여러분들이 Postman을 사용해서 Controller에 요청을 하기 위해서는 reqeust body 데이터가 필요합니다. Controller를 테스트하기 위해서는 (5)의 단계에서 테스트용 request body를 직접 만들어 주어야 합니다. Given-When-Then 패턴에서 Given에 해당됩니다.
- (6)에서는 MockMvc 객체를 통해 요청 URI와 HTTP 메서드등을 지정하고, (5)에서 만든 테스트용 request body를 추가한 뒤에 request를 수행합니다. Given-When-Then 패턴에서 When에 해당됩니다.
- (7)에서는 Controller에서 전달받은 HTTP Status와 response body 데이터를 통해 검증 작업을 진행합니다. Given-When-Then 패턴에서 Then에 해당됩니다.
MemberController 테스트
Controller의 테스트 진행 방법을 단계적으로 살펴보았으니 이제 실제로 우리가 작성한 MemberController에 대한 테스트 케이스를 작성해 보도록 하겠습니다.
HTTP Post request에 대한 테스트
package com.springboot.slice.controller.member;
import com.springboot.member.dto.MemberDto;
import com.google.gson.Gson;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.http.MediaType;
import org.springframework.test.web.servlet.MockMvc;
import org.springframework.test.web.servlet.ResultActions;
import org.springframework.transaction.annotation.Transactional;
import static org.hamcrest.Matchers.is;
import static org.hamcrest.Matchers.startsWith;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.post;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.header;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;
@SpringBootTest
@AutoConfigureMockMvc
class MemberControllerTest {
@Autowired
private MockMvc mockMvc;
@Autowired
private Gson gson;
@Test
void postMemberTest() throws Exception {
// given (1)
MemberDto.Post post = new MemberDto.Post("hgd@gmail.com",
"홍길동",
"010-1234-5678");
String content = gson.toJson(post); // (2)
// when
ResultActions actions =
mockMvc.perform( // (3)
post("/v11/members") // (4)
.accept(MediaType.APPLICATION_JSON) // (5)
.contentType(MediaType.APPLICATION_JSON) // (6)
.content(content) // (7)
);
// then
actions
.andExpect(status().isCreated()) // (8)
.andExpect(header().string("Location", is(startsWith("/v11/members/")))); // (9)
}
}
[코드 3-192] MemberController의 postMember() 테스트
코드 3-192는 MemberController의 postMember() 핸들러 메서드를 테스트하는 테스트 케이스입니다.
Controller를 테스트하는 기본 구조에 우리가 테스트하고자하는 로직들을 포함을 시켰습니다.
복잡해 보이지만 Given-When-Then 구조로 나누었기 때문에 단계적으로 접근하면 테스트 케이스를 조금 더 수월하게 작성할 수 있습니다. 코드 3-192의 설명은 아래와 같습니다.
- Given
- (1)의 코드는 Given에 해당되며 여러분들이 Postman을 사용할 때 request body에 포함시키는 요청 데이터와 동일한 역할을 합니다.
- Postman에서 등록할 회원 정보를 JSON 포맷으로 request body에 포함시키는 것 기억나시나요? (2)에서 Gson이라는 JSON 변환 라이브러리를 이용해서 (1)에서 생성한 MemberDto.Post 객체를 JSON 포맷으로 변환해줍니다.
- When
- MockMvc로 테스트 대상 Controller의 핸들러 메서드에 요청을 전송하기 위해서는 기본적으로 (3)과 같이 perform() 메서드를 호출해야 하며 perform() 메서드 내부에 Controller 호출을 위한 세부적인 정보들이 포함됩니다.
- (4) - (7) 까지는 HTTP request에 대한 정보이며, MockMvcRequestBuilders 클래스를 이용해서 빌더 패턴을 통해 request 정보를 채워 넣을 수 있습니다.
- (4)에서 post() 메서드를 통해 HTTP POST METHOD와 request URL을 설정합니다.
- (5)에서 accept() 메서드를 통해 클라이언트 쪽에서 리턴 받을 응답 데이터 타입으로 JSON 타입을 설정합니다.
- (6)에서 contentType() 메서드를 통해 서버 쪽에서 처리 가능한 Content Type으로 JSON 타입을 설정합니다.
- (7)에서 content() 메서드를 통해 request body 데이터를 설정합니다.
- request body에 전달하는 데이터는 (2)에서 Gson 라이브러리를 이용해 변환된 JSON 문자열입니다.
Spring에서는 post()와 같이 HTTP METHOD에 해당하는 request를 수행하는 다양한 메서드를 지원합니다.
request를 수행하는 메서드를 더 알아보고 싶다면 아래 \[심화 학습]을 참고하세요.
- Then
- MockMvc의 perform() 메서드는 ResultActions 타입의 객체를 리턴하는데, 이 ResultActions 객체를 이용해서 우리가 전송한 request에 대한 검증을 수행할 수 있습니다.
- (8)에서 andExpect() 메서드를 통해 파라미터로 입력한 매처(Matcher)로 예상되는 기대 결과를 검증할 수 있습니다.
- (8)에서는 status().isCreated()를 통해 response status가 201(Created)인지 매치시키고 있습니다. 즉, 백엔드 측에 리소스인 회원 정보가 잘 생성(저장)되었는지를 검증합니다.
- (9)에서 header().string("Location", is(startsWith("/v11/members/")))을 통해 HTTP header에 추가된 Location의 문자열 값이 “/v11/members/”로 시작하는지 검증합니다.
- Location header가 예상하는 값과 일치한다라는 것은 백엔드 측에 리소스(회원 정보)가 잘 생성되었다는 것을 의미합니다.
이제 MemberController의 postMember()에 대한 기본적인 테스트가 이루어졌습니다.
postMember()의 경우, 클라이언트에게 되돌려주는 response body는 없기 때문에 코드 3-192와 같이 단순히 기대하는 response status와 Location header의 값만 테스트하면 됩니다.
MemberController에 대한 테스트 케이스를 하나만 더 작성해 보도록 합시다.
이번에는 getMember() 핸들러 메서드를 테스트해 보겠습니다. getMember()의 경우, 특정 회원 정보 조회를 위한 request가 MemberController 쪽에 잘 전송되는지 그리고 request를 전달받은 getMember()가 request에 해당하는 회원 정보를 response로 잘 전달하는지를 확인하면 됩니다.
getMember()가 특정 회원 정보를 response로 잘 전달하는지를 테스트하려면 어떻게 해야 할까요?
이 경우에는 회원 정보 한 건을 먼저 백엔드 서버 측에 저장한 후, 방금 백엔드 서버 측에 저장한 리소스를 서버 측에 조회해서 조회가 잘 되는지 확인해 보면 될 것입니다.
package com.springboot.slice.controller.member;
import com.springboot.member.dto.MemberDto;
import com.google.gson.Gson;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.http.MediaType;
import org.springframework.test.web.servlet.MockMvc;
import org.springframework.test.web.servlet.ResultActions;
import org.springframework.transaction.annotation.Transactional;
import org.springframework.web.util.UriComponentsBuilder;
import java.net.URI;
import static org.hamcrest.Matchers.is;
import static org.hamcrest.Matchers.startsWith;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.post;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.jsonPath;
@Transactional
@SpringBootTest
@AutoConfigureMockMvc
class MemberControllerTest {
@Autowired
private MockMvc mockMvc;
@Autowired
private Gson gson;
...
...
@Test
void getMemberTest() throws Exception {
// =================================== (1) postMember()를 이용한 테스트 데이터 생성 시작
// given
MemberDto.Post post = new MemberDto.Post("hgd@gmail.com","홍길동","010-1111-1111");
String postContent = gson.toJson(post);
ResultActions postActions =
mockMvc.perform(
post("/v11/members")
.accept(MediaType.APPLICATION_JSON)
.contentType(MediaType.APPLICATION_JSON)
.content(postContent)
);
// =================================== (1) postMember()를 이용한 테스트 데이터 생성 끝
// (2)
String location = postActions.andReturn().getResponse().getHeader("Location"); // "/v11/members/1"
// when / then
mockMvc.perform(
get(location) // (3)
.accept(MediaType.APPLICATION_JSON)
)
.andExpect(status().isOk()) // (4)
.andExpect(jsonPath("$.data.email").value(post.getEmail())) // (5)
.andExpect(jsonPath("$.data.name").value(post.getName())) // (6)
.andExpect(jsonPath("$.data.phone").value(post.getPhone())); // (7)
}
}
[코드 3-193] MemberController의 getMember() 테스트
코드 3-193은 MemberController의 getMember() 핸들러 메서드를 테스트하는 테스트 케이스입니다. 코드 3-193의 테스트케이스 역시 Given-When-Then 구조로 나누어 생각해 볼 수 있습니다.
코드 3-192의 설명은 아래와 같습니다.
- Given
- (1)의 코드 영역은 우리가 코드 3-192에서 postMember()를 테스트할 때의 코드와 동일한 코드입니다. (1)을 통해서 테스트 데이터를 백엔드 서버 측의 데이터베이스에 먼저 저장합니다.
- (2)에서는 postMember()의 response에 전달되는 Location header 값을 가져오는 로직입니다. (2)와 같이 postActions.andReturn().getResponse().getHeader("Location")로 접근해서 Location header의 값을 얻어올 수 있습니다.
- When
- (3)에서는 (2)에서 얻은 Location header의 값을 get(location)으로 전달합니다. Location header에서 얻게 되는 값이 (1)에서 등록한 resource(회원 정보)의 위치(”/v11/members/1”)를 의미하기 때문에 get(…)의 URI로 전달하면 됩니다.
- Then
- (4)에서는 기대하는 HTTP status가 200 OK인지를 검증합니다.
- (5)에서 (7) 까지는 getMember() 핸들러 메서드에서 리턴하는 response body(JSON 형식)의 각 프로퍼티(email, name, phone)의 값을 검증하는 기능을 추가했습니다.
- (5)에서는 jsonPath() 메서드를 통해 response body(JSON 형식)의 각 프로퍼티 중에서 응답으로 전달받는 email 값이 request body로 전송한 email과 일치하는지 검증하고 있습니다.
- (6)에서는 jsonPath() 메서드를 통해 response body(JSON 형식)의 각 프로퍼티 중에서 응답으로 전달받는 name 값이 request body로 전송한 name과 일치하는지 검증하고 있습니다.
- (7)에서는 jsonPath() 메서드를 통해 response body(JSON 형식)의 각 프로퍼티 중에서 응답으로 전달받는 phone 값이 request body로 전송한 phone과 일치하는지 검증하고 있습니다.
MockMvcResultMatchers 클래스에서 지원하는 jsonPath()를 사용하면 JSON 형식의 개별 프로퍼티에 손쉽게 접근할 수 있다는 사실을 기억해 주세요!
MockMvcResultMatchers와 jsonPath()에 대해서 더 알아보고 싶다면 아래 **\[심화 학습]**을 참고하세요.
지금까지 @SpringBootTest, @AutoConfigureMockMvc 애너테이션을 사용해서 Controller 테스트를 손쉽게 진행하는 방법을 살펴보았습니다.
✅ response body 응답 데이터에 포함된 한글이 깨질 경우
만약 코드 3-193의 getMemberTest() 메서드 맨 아래쪽에 System.out.println(actions.andReturn().getResponse().getContentAsString());와 같은 코드를 추가해서 response body를 출력할 때, JSON 데이터에서 한글이 깨져 보일 경우, application.yml 파일에 아래의 설정을 추가합니다.
...
...
server:
servlet:
encoding:
force-response: true
✅
그런데 이번 챕터에서 학습한 Controller 테스트 방법에서 문제점을 한 가지 발견할 수 있습니다.
이번 챕터에서 학습한 방법대로 테스트할 경우, Controller만 테스트하는 것이 아니라 애플리케이션의 전체 로직을 모두 실행하게 됩니다.
즉, 우리가 테스트에 집중해야 되는 계층은 API 계층인데 서비스 계층이나 데이터 액세스 계층까지 불필요한 로직이 수행된다는 것입니다.
따라서 이번 챕터에서 학습한 방법만으로는 완전한 슬라이스 테스트라고 보기에는 힘듭니다.
이 문제는 Mock(가짜) 객체를 사용해 계층 간의 연결을 끊어줌으로써 해결이 가능합니다.
Mock 객체에 대한 내용은 Mockito 챕터에서 학습할 예정이므로 조금만 기다려주세요!
@WebMvcTest를 이용한 Controller 테스트
Spring에서는 Controller를 테스트하기 위한 전통적인 방법으로 @WebMvcTest 애너테이션을 사용할 수 있습니다.
하지만 @WebMvcTest 애너테이션을 사용할 경우, Controller에서 의존하는 컴포넌트들을 모두 일일이 설정해 주어야 하는 불편함이 있습니다.
예를 들어 MemberController에서 사용되는 MemberService Bean, MemberMapper Bean 객체 등을 테스트 클래스에서 사용할 수 있도록 설정해 주어야 합니다.
또한 때에 따라서 데이터액세스 계층에서 의존하는 설정이나 의존 객체들도 모두 설정해 주어야 할 수도 있습니다.
이런 이유로 이번 챕터에서는 @SpringBootTest, @AutoConfigureMockMvc를 이용해서 Controller 테스트를 위한 구성의 복잡함을 해결하고 있다는 사실을 기억해 주세요.
@WebMvcTest와 @SpringBootTest는 각각 장단점이 존재하며, 상황에 맞게 적절하게 사용할 수 있습니다.
@WebMvcTest는 API 문서화 유닛에서 사용해 보도록 하겠습니다.
핵심 포인트
- 개발자가 각 계층에 구현해 놓은 기능들이 잘 동작하는지 특정 계층만 잘라서(Slice) 테스트하는 것을 슬라이스 테스트(Slice Test)라고 한다.
- @SpringBootTest 애너테이션은 Spring Boot 기반의 애플리케이션을 테스트하기 위한 Application Context를 생성한다.
- @AutoConfigureMockMvc 애너테이션은 Controller 테스트를 위한 애플리케이션의 자동 구성 작업을 해준다.
- MockMvc는 Tomcat 같은 서버를 실행하지 않고 Spring 기반 애플리케이션의 Controller를 테스트할 수 있는 완벽한 환경을 지원해 주는 일종의 Spring MVC 테스트 프레임워크이다.
- MockMvc로 테스트 대상 Controller의 핸들러 메서드에 요청을 전송하기 위해서는 기본적으로 perform() 메서드를 먼저 호출해야 한다.
- MockMvcRequestBuilders 클래스를 이용해서 빌더 패턴을 통해 request 정보를 채워 넣을 수 있다.
- MockMvc의 perform() 메서드가 리턴하는 ResultActions 타입의 객체를 이용해서 request에 대한 검증을 수행할 수 있다.
심화 학습
- 스모크 테스트(Smoke Test)에 대해서 더 알아보고 싶다면 아래 링크를 참고하세요.
- MockMvc의 기능에 대해서 더 알아보고 싶다면 아래 링크를 참고하세요.
- MockMvc에서 지원하는 post()와 같이 request를 수행하는 메서드를 더 알아보고 싶다면 아래 링크를 참고하세요.
- MockMvcResultMatchers와 jsonPath()에 대해서 더 알아보고 싶다면 아래 링크를 참고하세요.
- https://www.baeldung.com/guide-to-jayway-jsonpath
- https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/test/web/servlet/result/MockMvcResultMatchers.html#jsonPath-java.lang.String-java.lang.Object...
- https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/test/web/servlet/result/JsonPathResultMatchers.html
- https://github.com/json-path/JsonPath
[기본] 데이터 액세스 계층 테스트
이번 시간에는 데이터 액세스 계층을 테스트하는 방법을 알아보도록 하겠습니다.
여러분들이 현재 데이터 액세스 계층에서 사용하고 있는 기술은 Spring Data JPA입니다.
Spring에서는 JPA에 대한 테스트를 쉽게 진행할 수 있는 몇 가지 방법들을 제공하는데 이번 시간에 자세히 살펴보도록 하겠습니다.
이번 챕터에서 살펴보는 데이터 액세스 계층의 테스트 방법은 JPA와 어느 정도 밀접한 관련이 있습니다.
실무에서 대부분 JPA를 사용하기 때문에 이 방식만 알아도 큰 문제는 없지만 Spring JDBC나 Spring Data JDBC 등에 대한테스트 방법 역시 지원하고 있다는 사실을 기억하면 좋을 것 같습니다. (챕터 하단에서 다시 설명합니다.)
데이터 액세스 계층을 테스트하기 위한 한 가지 규칙
데이터 액세스 계층 테스트 시에는 아래와 같은 한 가지 규칙을 지키는 것이 좋습니다.
- DB의 상태를 테스트 케이스 실행 이전으로 되돌려서 깨끗하게 만든다.
public class DataAccessLayerTest {
@Test
public void testA() {
// (1-1) 데이터가 DB에 잘 저장되는지를 테스트하기 위해 한 건의 데이터를 DB에 저장
// (1-2) DB에 잘 저장되었는지 DB에서 조회해서 결과를 확인
}
@Test
public void testB() {
// (2-1) 데이터가 DB에서 잘 조회 되는지를 테스트하기 위해 DB에서 조회
}
}
[코드 3-194] 데이터 액세스 계층 테스트에서 문제가 발생할 수 있는 사례
코드 3-194는 JUnit으로 데이터 액세스 계층을 테스트하는 이론적인 예입니다.
일반적으로 데이터액세스 계층을 테스트하기 위해 데이터베이스에 저장하는 테스트 데이터는 테스트 케이스를 실행할 때 대부분 같은 데이터로 테스트를 진행합니다.
테스트 케이스마다 각각 다른 데이터를 매번 각각의 테스트 케이스에 입력으로 전달한다는 건 비효율적일 테니까요. (테스트는 빠르게 실행할 수 있어야 한다는 사실 기억나시죠? )
그리고 JUnit으로 작성한 테스트 케이스는 항상 일정한 순서로 테스트 케이스가 실행된다는 보장이 없습니다.
예를 들어, DataAccessLayerTest 클래스 내의 전체 테스트 케이스를 실행했더니, 다음과 같은 순서로 테스트 케이스가 실행된다고 가정해 보겠습니다.
- testA() 실행
- (1-1) 테스트 데이터 한 건을 DB에 저장합니다.
- (1-2) DB에 잘 저장되었는지 DB에서 조회하여 결과를 검증합니다.
- 다음으로 testB() 실행
- (2-1) 특정 데이터가 DB에서 잘 조회되는지 기본키를 WHERE 조건으로 해서 DB에서 조회합니다.
- 만약 testA()에서 INSERT 한 데이터의 기본키를 WHERE 조건으로 테스트하면 조회가 되므로 테스트 결과는 “passed”일 것입니다.
그런데, 다시 테스트 케이스 전체를 실행했는데, 이번에는 실행 순서가 바뀌어서 testB()가 먼저 실행이 되었습니다.
이 경우에는 어떻게 될까요?
이미 테스트 케이스에 입력으로 전달한 WHERE 조건의 값이 고정된 상태에서 DB에 조회를 했는데 원하는 결과 값이 없기 때문에 테스트 결과는 “failed”일 것입니다.
첫 번째 경우는 testA()가 먼저 실행이 되었기 때문에 테스트 결과가 “passed”이지만 두 번째 경우는 testA() 먼저 실행이 되지 않았기 때문에 INSERT 된 데이터가 없기 때문입니다.
이처럼 테스트 케이스는 여러 개의 테스트 케이스를 일괄적으로 실행시키더라도 각각의 테스트 케이스에 독립성이 보장되어야 합니다.
이러한 문제가 발생하지 않도록 하는 가장 좋은 방법은 테스트 케이스 하나가 실행될 때, 해당 테스트 케이스에서 사용했던 데이터가 DB에 저장이 되어 있는 상태라면 테스트 케이스 실행 종료 시점에 저장되었던 데이터를 삭제해 주는 것입니다.
즉, DB의 상태를 테스트 케이스 실행 이전으로 되돌려서 깨끗하게 만드는 것입니다.
이 점을 염두에 두고, 이후의 학습을 진행하도록 하겠습니다.
MemberRepository 테스트
그럼 이제 우리가 구현하고 있는 커피 주문 샘플 애플리케이션에서 MemberRepository를 테스트해보도록 하겠습니다.
✅ 회원 정보 저장 테스트
package com.springboot.slice.repository.member;
import com.springboot.member.entity.Member;
import com.springboot.member.repository.MemberRepository;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest;
import static org.junit.jupiter.api.Assertions.*;
@DataJpaTest // (1)
public class MemberRepositoryTest {
@Autowired
private MemberRepository memberRepository; // (2)
@Test
public void saveMemberTest() {
// given (3)
Member member = new Member();
member.setEmail("hgd@gmail.com");
member.setName("홍길동");
member.setPhone("010-1111-2222");
// when (4)
Member savedMember = memberRepository.save(member);
// then (5)
assertNotNull(savedMember); // (5-1)
assertTrue(member.getEmail().equals(savedMember.getEmail()));
assertTrue(member.getName().equals(savedMember.getName()));
assertTrue(member.getPhone().equals(savedMember.getPhone()));
}
}
[코드 3-195] MemberRepository의 데이터 저장 테스트 예
코드 3-195에서는 MemberRepository의 save() 메서드가 잘 동작하는지 테스트하고 있습니다.
- Spring에서 데이터 액세스 계층을 테스트하기 위한 가장 핵심적인 방법은 바로 (1)과 같이 @DataJpaTest 애너테이션입니다.@DataJpaTest 애너테이션은 @Transactional 애너테이션을 포함하고 있기 때문에 하나의 테스트 케이스 실행이 종료되는 시점에 데이터베이스에 저장된 데이터는 rollback 처리됩니다.
- 즉, 여러 개의 테스트 케이스를 한꺼번에 실행시켜도 하나의 테스트 케이스가 종료될 때마다 데이터베이스의 상태가 초기 상태를 유지한다는 것입니다.
- @DataJpaTest 애너테이션을 테스트 클래스에 추가함으로써, MemberRepository의 기능을 정상적으로 사용하기 위한 Configuration을 Spring이 자동으로 해주게 됩니다.
- (2)에서 테스트 대상 클래스인 MemberRepository를 DI 받습니다.
- (3)에서 테스트할 회원 정보 데이터(member)를 준비합니다.
- (4)에서 회원 정보를 저장합니다.
- (5)에서 회원 정보가 잘 저장되었는지 검증(Assertion)합니다.
- 먼저 (5-1)과 같이 회원 정보를 정상적으로 저장한 뒤에 리턴 값으로 반환된 Member 객체(savedMember)가 null이 아닌지를 검증합니다.
- 나머지는 리턴 값으로 반환된 Member 객체(savedMember)의 필드들이 테스트 데이터와 일치 하는지 검증합니다.
이처럼 Spring에서 데이터 액세스 계층의 기능을 테스트하는 건 어렵지 않습니다.
바로 @DataJpaTest라는 애너테이션이 있기 때문입니다.
@DataJpaTest 애너테이션은 아래와 같은 자동 구성 기능들을 임포트(Import) 해줍니다.
org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration
org.springframework.boot.autoconfigure.data.jpa.JpaRepositoriesAutoConfiguration
org.springframework.boot.autoconfigure.flyway.FlywayAutoConfiguration
org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration
org.springframework.boot.autoconfigure.jdbc.DataSourceTransactionManagerAutoConfiguration
org.springframework.boot.autoconfigure.jdbc.JdbcTemplateAutoConfiguration
org.springframework.boot.autoconfigure.liquibase.LiquibaseAutoConfiguration
org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration
org.springframework.boot.autoconfigure.sql.init.SqlInitializationAutoConfiguration
org.springframework.boot.autoconfigure.transaction.TransactionAutoConfiguration
org.springframework.boot.test.autoconfigure.jdbc.TestDatabaseAutoConfiguration
org.springframework.boot.test.autoconfigure.orm.jpa.TestEntityManagerAutoConfiguration
@DataJpaTest 은 Spring Boot의 모든 자동 구성을 활성화하는 것이 아니라 데이터 액세스 계층에 필요한 자동 구성을 활성화한다는 사실을 기억하세요.
✅ 회원 정보 조회 테스트
이번에는 MemberRepository에서 중복된 이메일 주소가 있는지를 조회하는 기능의 findByEmail((String email) 메서드가 조회를 잘하는지 테스트해 보도록 하겠습니다.
package com.springboot.slice.repository.member;
import com.springboot.member.entity.Member;
import com.springboot.member.repository.MemberRepository;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest;
import java.util.Optional;
import static org.junit.jupiter.api.Assertions.*;
@DataJpaTest
public class MemberRepositoryTest {
...
...
@Test
public void findByEmailTest() {
// given (1)
Member member = new Member();
member.setEmail("hgd@gmail.com");
member.setName("홍길동");
member.setPhone("010-1111-2222");
// when
memberRepository.save(member); // (2)
Optional<Member> findMember = memberRepository.findByEmail(member.getEmail()); // (3)
// then (4)
assertTrue(findMember.isPresent()); // (4-1)
assertTrue(findMember.get().getEmail().equals(member.getEmail())); // (4-2)
}
}
[코드 3-196] MemberRepository의 데이터 조회 테스트 예
코드 3-196에서는 MemberRepository의 save() 메서드가 잘 동작하는지 테스트하고 있습니다.
- (1)에서 테스트할 회원 정보 데이터(member)를 준비합니다.
- (2)에서 회원 정보를 저장합니다.
- 이번에는 (2)에서 저장 후, 리턴되는 Member 객체를 이용하는 것이 아니라 (2)에서 저장한 회원 정보 중에서 이메일에 해당되는 회원 정보를 잘 조회하는지 테스트하기 위해 (3)과 같이 findByEmail()로 회원 정보를 조회하고 있습니다.
- (4)에서 회원 정보의 조회가 정상적으로 이루어지는지 검증(Assertion)합니다.
- 먼저 (4-1)과 같이 조회된 회원 정보가 null이 아닌지를 검증합니다.
- (4-2)에서 조회한 회원의 이메일 주소와 테스트 데이터의 이메일과 일치하는지 검증합니다.
Spring JDBC나 Spring Data JDBC 환경에서 테스트 환경을 손쉽게 구성할 수 있는 방법은 없을까?
방법이 있습니다. Spring JDBC 환경에서는 @JdbcTest, Spring Data JDBC 환경에서는 @DataJdbcTest를 사용하면 손쉽게 데이터 액세스 계층에 대한 테스트를 진행할 수 있습니다.
핵심 포인트
- 데이터 액세스 계층 테스트 시에는 테스트 종료 직 후, DB의 상태를 테스트 케이스 실행 이전으로 되돌려서 깨끗하게 만든다.
- @DataJpaTest 애너테이션을 사용하면 Spring Data JPA 환경에서 데이터 액세스 계층의 테스트를 손쉽게 진행할 수 있다.
- @DataJpaTest 애너테이션은 @Transactional 애너테이션을 포함하고 있기 때문에 하나의 테스트 케이스 실행이 종료되는 시점에 데이터베이스에 저장된 데이터는 rollback 처리된다.
심화 학습
- @DataJpaTest 애너테이션에 대해서 더 알아보고 싶다면 아래 링크를 참고하세요.
[실습] 슬라이스 테스트 실습
MockMvc를 사용한 Controller 슬라이스 테스트 실습 개요
이번 실습은 Spring의 MockMvc를 사용하여 API 계층의 Controller가 클라이언트의 요청을 잘 전달받는지에 대한 슬라이스 테스트를 적용해보는 실습입니다.
- 지난 챕터까지 학습했던 구현 코드들이 기본적으로 포함이 되어 있으며, 이를 기반으로 요구 사항에 맞게 Controller에 대한 슬라이스 테스트를 할 수 있는 테스트 케이스를 작성하면 됩니다.
- 실습용 프로젝트 패키지는 ‘com.springboot’ 패키지 하위에 아래와 같이 구성되어 있습니다.
- advice
- audit
- coffee
- config
- dto
- exception
- member
- order
- response
- stamp
- validator
- 테스트 케이스는 일반적으로 Gradle 기반 프로젝트에서 ‘src/test/java/**’ 경로에 작성합니다.
- 여러분들이 작성할 테스트 케이스 역시 ‘src/test/java/com/springboot/homework’의 실습 과제용 테스트 케이스 내부에 포함 되어 있습니다.
실습 사전 준비
- 실습용 샘플 프로젝트 복제
- 아래 github 링크에서 실습용 repository를 fork합니다.
- fork한 repository를 여러분의 PC에서 git clone 명령으로 local repository에 복제합니다.
- IntelliJ IDE로 clone 받은 forked local repository 디렉토리의 프로젝트를 Open합니다.
- 아래 실습 요구 사항에 따라 실습을 진행합니다.
- 작성한 코드는 main branch에 작성해 주세요.
- main branch가 아닌 별도의 branch를 생성해서 작업을 했다면 작업이 끝난 후, 반드시 main branch로 merge 해야 합니다.
실습 과제 내용
실습 1: MemberController 클래스에 대한 슬라이스(Slice) 테스트 케이스 작성
- 테스트 케이스 작성을 위한 설명
- 현재 여러분들이 완성해야 할 MemberControllerHomeworkTest 테스트 클래스가 아래 경로에 비어 있는 채로 작성되어 있습니다.
- src/test/java/com/springboot/homework/MemberControllerHomeworkTest.java
- MemberControllerHomeworkTest 테스트 클래스에서 비어 있는 아래 테스트 케이스를 작성해 주세요.
- patchMemberTest()
- MemberController 클래스의 patchMember() 핸들러 메서드를 테스트하기 위한 테스트 케이스입니다.
- getMembersTest()
- MemberController 클래스의 getMembers() 핸들러 메서드를 테스트하기 위한 테스트 케이스입니다.
- deleteMemberTest()
- MemberController 클래스의 deleteMember() 핸들러 메서드를 테스트하기 위한 테스트 케이스입니다.
- patchMemberTest()
- 현재 여러분들이 완성해야 할 MemberControllerHomeworkTest 테스트 클래스가 아래 경로에 비어 있는 채로 작성되어 있습니다.
- 제한 사항
- 테스트에 대한 별도의 제한 사항은 없습니다. 여러분들이 해당 Controller 클래스의 핸들러 메서드를 원하는 방법대로 테스트할 수 있도록 테스트 케이스를 작성하면 됩니다.
- 테스트 입력 값에 별도의 제한 사항은 없습니다.
- 여러분이 다양한 상황을 테스트해보세요.
- 테스트 케이스 작성에 있어서의 조언
- 일반적으로 테스트 대상 핸들러 메서드를 테스트하기 전에 DB에 데이터가 먼저 저장되어 있어야 합니다.
- 여러분들이 아직 Mock에 대한 학습을 진행하지 않았기 때문에 테스트 데이터가 DB에 저장되는 프로세스는 현재 시점에서는 아마 반드시 필요할 거라고 생각합니다.
- 여러분들이 작성하는 테스트 케이스를 실행할 때마다 테스트 데이터를 DB에 먼저 저장할 수 있는 방법을 고민해 보세요.
- 방법은 여러 가지가 있을 것이고, 그중에 정답이 있거나 한 것은 아니니 자유롭게 고민해 보길 바랍니다.
- Controller의 핸들러 메서드에서 어떤 테스트를 해볼 수 있을까요?
- 요청을 보낸 핸들러 메서드가 기대하는 응답 데이터를 잘 전송해 주는지를 테스트해볼 수 있습니다.
- DTO 클래스 또는 요청 URI에 적용된 유효성 검증에 대한 테스트를 해볼 수 있습니다.
- 보안을 아직 학습하지 않았지만 보안 기능이 적용되어 있다면 요청을 전송하는 사용자가 해당 핸들러에 접근할 수 있는 적절한 권한이 있는지를 테스트해볼 수 있습니다.
- 일반적으로 테스트 대상 핸들러 메서드를 테스트하기 전에 DB에 데이터가 먼저 저장되어 있어야 합니다.
MemberControllerHomeworkTest
package com.springboot.homework;
import com.springboot.member.dto.MemberDto;
import com.google.gson.Gson;
import com.springboot.member.dto.MemberPatchDto;
import com.springboot.member.repository.MemberRepository;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.http.MediaType;
import org.springframework.test.web.servlet.MockMvc;
import org.springframework.test.web.servlet.ResultActions;
import org.springframework.transaction.annotation.Transactional;
import org.springframework.util.LinkedMultiValueMap;
import org.springframework.util.MultiValueMap;
import org.springframework.web.util.UriComponentsBuilder;
import java.net.URI;
import java.util.ArrayList;
import java.util.List;
import static com.springboot.member.entity.Member.MemberStatus.MEMBER_ACTIVE;
import static org.hamcrest.Matchers.is;
import static org.hamcrest.Matchers.startsWith;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.*;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*;
@Transactional
@SpringBootTest
@AutoConfigureMockMvc
public class MemberControllerHomeworkTest {
@Autowired
private MockMvc mockMvc;
@Autowired
private Gson gson;
@Autowired
private MemberRepository memberRepository;
@Test
void postMemberTest() throws Exception {
// given
MemberDto.Post post = new MemberDto.Post("hgd@gmail.com",
"홍길동",
"010-1234-5678");
String content = gson.toJson(post);
// when
ResultActions actions =
mockMvc.perform(
post("/v11/members")
.accept(MediaType.APPLICATION_JSON)
.contentType(MediaType.APPLICATION_JSON)
.content(content)
);
// then
actions
.andExpect(status().isCreated())
.andExpect(header().string("Location", is(startsWith("/v11/members/"))));
}
@Test
void patchMemberTest() throws Exception {
// TODO MemberController의 patchMember() 핸들러 메서드를 테스트하는 테스트 케이스를 여기에 작성하세요.
// given
// memberController의 patchMember()를 테스트하기 위해서,
// MockMvc를 이용해 stub 데이터를 생성 후 진행
MemberDto.Post postMemberDto = new MemberDto.Post("hgd@gmail.com",
"홍길동",
"010-1234-5678");
String postContent = gson.toJson(postMemberDto);
// when
ResultActions postActions =
mockMvc.perform(
post("/v11/members")
.accept(MediaType.APPLICATION_JSON)
.contentType(MediaType.APPLICATION_JSON)
.content(postContent)
);
String location = postActions.andReturn().getResponse().getHeader("Location");
MemberDto.Patch patchMemberDto = MemberDto.Patch.builder()
.phone("010-9876-5421")
.build();
URI patchUri = UriComponentsBuilder.newInstance().path(location).build().toUri();
ResultActions patchActions = mockMvc.perform(
patch(patchUri)
.accept(MediaType.APPLICATION_JSON)
.contentType(MediaType.APPLICATION_JSON)
.content(gson.toJson(patchMemberDto))
);
// then
patchActions
.andExpect(status().isOk())
.andExpect(jsonPath("$.data.phone").value(patchMemberDto.getPhone()));
}
@Test
void getMemberTest() throws Exception {
// given: MemberController의 getMember()를 테스트하기 위해서 postMember()를 이용해 테스트 데이터를 생성 후, DB에 저장
MemberDto.Post post = new MemberDto.Post("hgd@gmail.com","홍길동","010-1111-1111");
String postContent = gson.toJson(post);
ResultActions postActions =
mockMvc.perform(
post("/v11/members")
.contentType(MediaType.APPLICATION_JSON)
.accept(MediaType.APPLICATION_JSON)
.content(postContent)
);
long memberId;
String location = postActions.andReturn().getResponse().getHeader("Location"); // "/v11/members/1"
memberId = Long.parseLong(location.substring(location.lastIndexOf("/") + 1));
// when / then
mockMvc.perform(
get("/v11/members/" + memberId)
.accept(MediaType.APPLICATION_JSON)
)
.andExpect(status().isOk())
.andExpect(jsonPath("$.data.email").value(post.getEmail()))
.andExpect(jsonPath("$.data.name").value(post.getName()))
.andExpect(jsonPath("$.data.phone").value(post.getPhone()));
}
@Test
void getMembersTest() throws Exception {
// TODO MemberController의 getMembers() 핸들러 메서드를 테스트하는 테스트 케이스를 여기에 작성하세요.
// given
// 2명 이상의 회원 정보를 등록
// 페이징 관련 정보를 담은 객체 만들기
List<MemberDto.Post> postMembers = new ArrayList<>(List.of(
new MemberDto.Post("luckt@gas.com", "김러키", "010-1234-5675"),
new MemberDto.Post("lattee@gas.com", "김라떼", "010-1543-5675")
));
for (MemberDto.Post member : postMembers) {
mockMvc.perform(
post("/v11/members")
.contentType(MediaType.APPLICATION_JSON)
.accept(MediaType.APPLICATION_JSON)
.content(gson.toJson(member)));
}
MultiValueMap<String, String> queryParams = new LinkedMultiValueMap<>();
queryParams.add("page", "1");
queryParams.add("size", "10");
URI getUri = UriComponentsBuilder.newInstance()
.path("/v11/members").build().toUri();
// when
ResultActions actions = mockMvc.perform(
get(getUri)
.params(queryParams)
.accept(MediaType.APPLICATION_JSON)
);
// then
actions.andExpect(status().isOk())
.andExpect(jsonPath("$.data[0].email").value(postMembers.get(1).getEmail()))
.andExpect(jsonPath("$.data[0].name").value(postMembers.get(1).getName()))
.andExpect(jsonPath("$.data[0].phone").value(postMembers.get(1).getPhone()))
.andExpect(jsonPath("$.data[1].email").value(postMembers.get(0).getEmail()))
.andExpect(jsonPath("$.data[1].name").value(postMembers.get(0).getName()))
.andExpect(jsonPath("$.data[1].phone").value(postMembers.get(0).getPhone()));
}
@Test
void deleteMemberTest() throws Exception {
// TODO MemberController의 deleteMember() 핸들러 메서드를 테스트하는 테스트 케이스를 여기에 작성하세요.
// given
MemberDto.Post postMemberDto = new MemberDto.Post("hgd@gmail.com",
"홍길동",
"010-1234-5678");
String postContent = gson.toJson(postMemberDto);
// when
ResultActions postActions =
mockMvc.perform(
post("/v11/members")
.accept(MediaType.APPLICATION_JSON)
.contentType(MediaType.APPLICATION_JSON)
.content(postContent)
);
String location = postActions.andReturn().getResponse().getHeader("Location");
URI uri = UriComponentsBuilder.newInstance().path(location).build().toUri();
// when / then
mockMvc.perform(
delete(uri))
.andExpect(status().isNoContent());
}
}