Spring Boot Test와 슬라이스 테스트

2022.03.06 SpringBootTest 내용 추가(추후 정리 예정)

 

System.out 같은 걸 사용하면 테스트 못하잖아요?
-> 인터페이스로 추상화해서 사용하고, 의존성을 분리시키면 가능합니다.

💨 외부의존성이 있는 객체는 Mockito 등을 이용해서 조작(Mocking)합니다.

- 물론 이를 조작하려면, 외부에서 내가 원하는 의존성을 생성자로 주입할 수 있어야합니다.
- 특정 메서드 ex) console.todayAsString() 가 실행되면, 내가 원하는 결과값을 반환하도록 조작할 수 있습니다.
- 특정 메서드가 실행되면 exception이 터지도록 만들 수도 있습니다.

@Mock Console console;
var myConsolePrinter = new MyConsolePrinter(console);

given(console.todayAsString()) // 상태를 조작, 이를 Mocking 이라 합니다. 
       .willReturn("01/04/2014", "02/04/2014", "10/04/2014");

var myService = new MyService(myConsolePrinter )

💨 실제 사용자 입장의 요구사항 확인을, 인수 테스트(Acceptance Test)라고 합니다.

- 이는 main 함수나, 실제 앱을 실행시켜서 테스트하는 경우도 포함합니다. 자주해봤죠. 
- 물론 Acceptance Test 도  테스트 코드로 만들 수 있습니다.

예를 들어 아래와 같은 main함수가 있을 때

public class BankApplication {
    public static void main(String[] args) {
        Clock clock = new Clock();
        TransactionRepository transactionRepository = new TransactionRepository(clock);
        Console console = new Console();
        StatementPrinter statementPrinter = new StatementPrinter(console);
        Account account = new Account(transactionRepository, statementPrinter);

        // 내가 확인하고 싶은 결과들, 여기선 실제 DB나 콘솔을 뒤져가며 결과를 확인해야합니다.
        account.deposit(1000);
        account.withdraw(100);
        account.deposit(500);
        account.printStatement();
    }
}

- 이를 ATDD (인수 TDD, AcceptanceTDD) 로 하면 이렇게 할 수 있습니다. 방금 설명한 Mocking 라이브러리를 이용한거죠.

@ExtendWith(MockitoExtension.class) // @Mock 사용을 위한 설정
public class PrintStatementFeature {
    @Mock Console console;
    @Mock Clock clock;
    private Account account;

    @BeforeEach
    void setUp() {
        TransactionRepository transactionRepository = new TransactionRepository(clock);
        StatementPrinter statementPrinter = new StatementPrinter(console);
        account = new Account(transactionRepository, statementPrinter);
    }

    @Test
    void print_statement_containing_all_transactions() {
        given(clock.todayAsString()).willReturn("01/04/2014", "02/04/2014", "10/04/2014");

        account.deposit(1000);
        account.withdraw(100);
        account.deposit(500);
        account.printStatement();

        // 미리 만들어둔 가짜객체(Mock)을 이용해서 테스트를 검증합니다.
        InOrder inOrder = inOrder(console);
        inOrder.verify(console).printLine("DATE | AMOUNT | BALANCE");
        inOrder.verify(console).printLine("10/04/2014 | 500.00 | 1400.00");
        inOrder.verify(console).printLine("02/04/2014 | -100.00 | 900.00");
        inOrder.verify(console).printLine("01/04/2014 | 1000.00 | 1000.00");
    }
}

 

 

💨 다만 조작하기 어려운 외부 의존성(콘솔, DB등)이 없다면, 굳이 Mockito를 사용하지 않아도됩니다. 

그냥 직접 SpyRepository RepositoryStub이런 이름의 가짜객체를 만들면 되거든요 

💨 실제 비즈니스 앱, 스프링에서도 다 가능합니다.

외부 API, 데이터베이스, 복잡한 의존성.. 다 테스트 가능합니다.
테스트의 대상이 (외부 의존성을 사용하는) 내가 만든 객체여야 의미가 있습니다.

외부의존성 자체를 테스트하는건 아무런 의미가 없습니다.
KakaoPay API 가 잘 동작하는지, MySQL DB 서버가 잘 동작하는지 스프링에서 테스트 하는 건 아무런 의미가 없죠.

💨 예를 들어 @SpringBootTest(webEnviroment=...) 는 아래와 같은 옵션이 있습니다.

MOCK (생략시 기본값) = MockMvc 사용
RANDOM_PORT, DEFINED_PORT = 포트를 지정해서 실제 톰캣을 띄워봄

// @SpringBootTest(webEnviroment=...)
= MOCK (생략시 기본값) = MockMvc 사용
= RANDOM_PORT, DEFINED_PORT = 포트를 지정해서 실제 톰캣을 띄워봄

Mock에서 테스트하려면 MockMvc를 사용해야하고
Random을 사용해서 실제 컨테이너에 상호작용해보려면 RestTemplate 나 WebClient를 써야하는데, 테스트 용도로 TestRestTemaplte WebTestClient 같은거도 제공해줍니다.

1.MockMvc 와 2. TestRestTemplate의 차이점은 1번은 단순히 디스패쳐 서블릿이 잘 동작하는가 테스트 해보는거고, 2번은 실제 컨테이너가 HTTP 요청을 잘 처리하는지 테스트합니다.

예를 들어, 서블릿에서 예외가 발생하면 결국 서블릿 컨테이너가 마지막에 처리하게 되는데

• TestRestTemplate은 실제 클라이언트가 HTTP 통신으로 예외페이지가 렌더링 되었는지 확인 가능하고
• MockMvc는 단순히 디스패쳐 서블릿이 예외를 잘 throw하고 전달했는지, 반환값을 잘 전달했는지 로직만을 확인할 수 있습니다.

+ 만약 서버입장이 아니라, 클라이언트 입장 테스트(ex 외부 API 호출코드) 하고싶다면 @RestClientTest 를 이용해 MockRestServiceServer를 만들어 테스트 가능합니다.

 

실제로 잘 돌아가는지 통합테스트를 해보려면 컨테이너를 띄우는게 맞겠지만 느리고 비용이 많이 들죠.

컨트롤러가 잘 동작하는지, 로직의 유효성을 파악하는데는 굳이 실제 컨테이너를 띄울 필요가 없으니까 MockMvc로 확인하는게 좋다고 합니다.

근데 사실 그런 경우라면 모든 빈을 컨테이너(AppContext)에 띄울 필요도 없으니까,
SpringBootTest 말고 테스트에 필요한 빈만 띄울 수 있는 @WebMvcTest 같은 슬라이스 테스트를 쓰는게 제일 테스트 속도가 빨라서 좋죠.

 

# MockMvc 사용법

요청 만들기

// 💨 MockMvcRequestBuilders는 RequestBuilder인터페이스의 구현 객체이다. 
// RequestBuilder reqBuilder = MockMvcRequestBuilders.get("/");
MockHttpServletRequestBuilder request = MockMvcRequestBuilders.get("/");

request.param("name", "이름")
       .content("content")
       .sessionAttr("session", "세션");

 

실행 결과는 아래와 같이 ResultActions로 받아 검증할 수 있다.

RequestBuilder request = MockMvcRequestBuilders.get("/admin/login");
var actions = mockMvc.perform(request); // 실행결과 받기, ResultActions 객체로 반환

actions.andDo(print())
    .andExpect(status().isOk())
    .andExpect(model().attributeExists("signUpForm"))
    .andExpect(view().name("account/sign-up"));

ResultActions 객체에 andExpect() 메서드가 있는데, 이 메서드는 인자 값으로 org.springframework.test.web.servlet.ResultMatcher 를 받는다

spring-boot-test에서 제공하는 팩토리 메서드인 MockMvcResultMatchers 클래스를 이용하면 쉽게 사용할 수 있다.

 

 

참고로 ResultActions에는 검증말고 특정 메서드를 실행할 수도 있다. 로그를 남긴다거나, 테스트 결과를 화면에 찍는다거나

ResultActions 의 메소드 

public static ResultHandler log()

: 실행 결과를 디버깅 레벨에서 로그로 출력한다. 로그를 출력할 때 사용되는 로거 이름은  org.springframework.test.web.servlet.result다

public static ResultHandler print()

: 실행 결과를 임의의 출력 대상에 출력한다. 출력대상을 지정하지 않으면 기본적으로 표준 출력(System.out)이 출력 대상이 된다

 

 

요청만들기 - MockHttpServletRequestBuilder

public MockHttpServletRequestBuilder param(String name, String... values)

public MockHttpServletRequestBuilder params(MultiValueMap<String,String> params)

: 요청파라미터를 설정한다

public MockHttpServletRequestBuilder header(String name, Object... values)

public MockHttpServletRequestBuilder headers(HttpHeaders httpHeaders)

: 요청 헤더를 설정한다. contentType이나 accept와 같은 특정 헤더를 설정할 수 있는 메서드도 제공한다.

public MockHttpServletRequestBuilder cookie(Cookie... cookies)

: 쿠키를 설정한다

public MockHttpServletRequestBuilder content(String content)

: 요청 본문을 설정한다

public MockHttpServletRequestBuilder requestAttr(String name, Object value)

: 요청스코프에 객체를 설정한다

public MockHttpServletRequestBuilder sessionAttr(String name, Object value)

public MockHttpServletRequestBuilder sessionAttrs(Map<String,Object> sessionAttributes)

: 세션 스코프에 객체를 설정한다.

public MockHttpServletRequestBuilder flashAttr(String name, Object value)

: 플래쉬 스코프에 객체를 설정한다.

 

검증 - MockMvcResultMatchers

public static ViewResultMatchers view()

: 컨트롤러가 반환한 뷰 이름을 검증한다.

public static StatusResultMatchers status()

: HTTP 상태 코드를 검증한다.

public static HeaderResultMatchers header()

: 응답 헤더의 상태를 검증한다.

public static ContentResultMatchers content()

: 응답 본문 내용을 검증한다. jsonPath나 xpath와 같은 특정 콘텐츠를 위한 메서드를 제공한다

public static CookieResultMatchers cookie()

: 쿠키의 상태를 검증한다

public static ModelResultMatchers model()

: 스프링 MVC 모델 상태를 검증한다.

public static ResultMatcher redirectedUrl(String expectedUrl)

: 리다이렉트 대상의 경로 또는 URL을 검증한다. 패턴으로 검증할 때는 redirectedUrlPattern 메서드를 사용한다.

public static ResultMatcher forwardedUrlPattern(String urlPattern)

: 이동 대상 경로를 검증한다. 패턴으로 검증할 때는 forwardedUrlPattern 메서드를 사용한다.

public static RequestResultMatchers request()

: 서블릿 3.부터 지원되는 비동기 처리의 상태나 요청스코프의 상태, 세션 스코프의 상태를 검증한다.

 

---

 

# 슬라이스 테스트가 왜 필요하죠?

슬라이스 테스트는 전체중 일부만 가져와서 하는 테스트라고 생각하면 된다.

• @SpringBootTest는 테스트와 상관없는 앱 설정, 모든 Bean들을 불러오기에 오래걸린다.
  ➡ @SpringBootTest는 단위테스트에 사용하기에 적합하지 않다.
• 테스트의 단위가 커져 디버깅이 어려워진다.
• 그렇다고 @Test만 사용하기에는 스프링 테스트 준비 작업이 너무 번거롭다.

 

# SpringBoot의 슬라이스 테스트

어노테이션을 테스트 Class에 붙여서 쉽게 사용할 수 있다. 예제코드와 함께 간단하게 알아보자.

 

@WebMvcTest - MockApiTest (MVC 관련된 Bean)

➡ MockMvc을 자동으로 생성/설정해주어 MVC와 관련된 단위테스트에서 사용된다.

➡ @Mock 처럼 사용할 수 있도록 스프링 빈을 위한 @MockBean 어노테이션을 제공해준다. (껍데기만 있음. 구현 X)

@WebMvcTest(PaymentController.class)
public class PaymentControllerTests {
    @AutoWired 
    private MockMvc mvc;
    
    @MockBean
    private PaymentService paymentService; 
    // PaymentService 내부에서 외부의 결제 대행 서비스를 사용하고 있는 상태라고 가정
  	
    @Test
    public void testPayment() throws Exception {
        // 5만원 금액 충전: 테스트 환경에서는 실패하는 행위이지만
        given(this.payMentService.chargePoint(50000L)) 
          .willReturn(new Point(50000L)); // 올바른 요청으로 간주하고 반환하도록 행위 지정
    }
}

// 테스트할 컨트롤러 클래스를 지정해주어야 한다.
@WebMvcTest(ArticleApiController.class)
public class ArticleApiControllerTest {

  @Autowired
  private MockMvc mockMvc; // MockMvc를 자동으로 설정해주며, 이를 이용해 테스트할 수 있다.
  
  @MockBean // 물론 MockBean을 사용하지 않고, 직접 가짜객체(Stub)을 만들어도 된다.
  private ArticleService articleService;

  @DisplayName("토큰과 이메일 정보로 검증요청을 보낸 경우 303 HTTP Code 리턴한다.")
  void valid_success() throws Exception {
     //Given
     var request = new LoginAccountRequest();
     request.setEmail(args);
     request.setPassword(args);

     //When. 참고로 굳이 actions 변수로 받지 않아도 사용가능하긴 하다.
     var actions = mockMvc.perform(post("/api/login")
         .accept(MediaType.APPLICATION_JSON) // accept 헤더 설정
         .content(objectMapper.writeValueAsString(request)) // content Body 설정
         .param("email","hi@naver.com") // 요청 파라미터 설정
      	
      );

      //Then
      actions
          .andDo(print()) // 테스트에 성공하더라도 콘솔에 Print하도록 한다.
          .andExpect(status().isOk())  //200코드
          .andExpect(jsonPath("$.id").isNumber()) // Json도 간단하게 확인가능
          .andExpect(jsonPath("$.email").isString())
          .andExpect(jsonPath("$.nickname").isString());
  }
}

 

 

참고로 컨트롤러에서 비동기로 응답 (Future나 DeferredResult를 반환)하는 경우 아래와 같이 사용하면 된다.

    // MvcResult 인터페이스로 비동기 응답을 받음 (Future, DeferredResult)    
    MvcResult result = mockMvc.perform(get("/api/articles/1")).andReturn();
    
    Mockmvc.perform(asyncDispatch(result)) // asyncDispatch를 이용.
            .andExpect(status().isOk())
            .andExpect(jsonPath("@.id").value(1));

 

---

@DataJpaTest - RepositoryTest (Jpa 관련  Bean)

➡ 인메모리 DB를 생성하고 @Transaction을 자동으로 붙여준다. JPA와 관련된 단위테스트에서 사용된다.

참고로 Spring Data JPA말고도 @JdbcTest, @DataMongoTest 등의 슬라이스 테스트도 있다.

// 프로젝트 내의 @Entity를 스캔하고, TestEntityManager 빈을 자동 설정해준다.
@DataJpaTest
public class ArticleDaoTest {

    @Autowired
    private TestEntityManager entityManager;
    @Autowired
    private ArticleDao articleDao;

    @Test
    public void test() {
        Article articleByKwseo = new Article(1, "kwseo", "good", "hello", Timestamp.valueOf(
            LocalDateTime.now()));
        Article articleByKim = new Article(2, "kim", "good", "hello",
            Timestamp.valueOf(LocalDateTime.now()));
        
        entityManager.persist(articleByKwseo);
        entityManager.persist(articleByKim);

        List<Article> articles = articleDao.findByAuthor("kwseo");
        assertThat(articles)
            .isNotEmpty()
            .hasSize(1)
            .contains(articleByKwseo)
            .doesNotContain(articleByKim);
    }
}

 

참고로 @DataJpaTest 안에는 @Transactional 키워드를 포함하고 있다. 만약 의도적으로 트랜잭션을 적용하고 싶지 않다면 아래와 같이 propagation을 바꿔주자.

// @Entity를 스캔하고 TestEntityManager 빈을 생성한다.
@DataJpaTest 
@Transactional(propagation = Propagation.NOT_SUPPORTED)
public class SomejpaTest {
    ...
}

 

---

@JsonTest

➡ JacksonTester를 생성해주며 JSON의 직렬화, 역직렬화해보고 파일과 비교하는 등의 테스트 해볼 수 있다.

@JsonTest
public class ArticleJsonTest {

    @Autowired
    private JacksonTester<Article> json;

    @Test
    public void testSerialize() throws IOException {
        Article article = new Article(
            1,
            "kwseo",
            "good",
            "good article",
            Timestamp.valueOf((LocalDateTime.now())));

        // assertThat(json.write(article)).isEqualToJson("expected.json");  직접 파일과 비교
        assertThat(json.write(article)).hasJsonPathStringValue("@.author");
        assertThat(json.write(article))
            .extractingJsonPathStringValue("@.title")
            .isEqualTo("good");
    }
}

 

---

@RestClientTest

➡ 요청에 반응하는 MockRestServiceServer 서버를 만들며, 클라이언트 입장에서 접속하는 것처럼 테스트한다.

@RestClientTest(ArticleServiceImpl.class)
public class ArticleServiceImplWithRestClientTest {

    @MockBean
    private ArticleDao dao;
    @Autowired
    private ArticleServiceImpl service;
    @Autowired
    private MockRestServiceServer server;

    @Test
    public void testGetFindOneFromRemote() throws Exception {
        String articleJson = ...;
		
        // 서버의 Response를 스터빙함. 
        server.expect(requestTo("http://sample.com/some/articles/1"))
            .andRespond(withSuccess(articleJson, MediaType.APPLICATION_JSON));
		
        // 게시판 article을 서버에서 받아옴
        Article article = service.findOneFromRemote(1);
        assertThat(article.getId()).isEqualTo(1);
    }
}

 

---

@WebFluxTest

➡ 스프링 WebFlux 와 관련된 컴포넌트를 자동 구축하고, 단위테스트에서 사용된다.

참고로 @WebFluxTest는 아래와 같은 설정이 포함되어 있다.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@BootstrapWith(WebFluxTestContextBootstrapper.class)
@ExtendWith(SpringExtension.class)
@OverrideAutoConfiguration(enabled = false)
@TypeExcludeFilters(WebFluxTypeExcludeFilter.class)
@AutoConfigureCache
@AutoConfigureJson
@AutoConfigureWebFlux
@AutoConfigureWebTestClient
@ImportAutoConfiguration
public @interface WebFluxTest {
}

 

참고로 WebFlux를 사용하지 않더라도 해당 테스트를 이용하면 BDD (Given-When-Then) 테스트를 간결하게 작성할 수 있다. 자세한건 아래 링크를 참고하자.

Spring WebFlux와 Kotlin으로 만드는 Todo 서비스 – 테스트 슬라이스 적용하기 | Popit