양's World

컨트롤러 핸들러메소드의 인자에 HTTP요청의 데이터를 자동으로 바인딩 받을 수 있다.
바인딩 받을 변수중에 LocalDateTime 타입의 변수가 있다면, 약속된 패턴으로 스트링 데이터를 보내주거나, VO에서 별도의 애너테이션(@JsonFormat, @DateTimeFormat) 설정을 해줘야 하는데 이에 관해 정리하고자 한다. 결과가 궁금한경우 테스트코드를 건너뛰고 결론만 봐도 된다.

RequestBody(JSON 데이터를 수신하는 경우)

• yyyy-MM-ddTHH:mm:ss 패턴으로 JSON 데이터를 보내면 VO에 애노테이션을 지정하지 않아도 바인딩된다.

// VO
public class TestVo {
    private LocalDateTime ldt;
    private String name;
}

// Controller
@RequestMapping(path = "/requestBody", method = RequestMethod.POST)
@ResponseBody
public String rbPost(@RequestBody TestVo dto){
    System.out.println("dto : " + dto);
      return "good";
}

// Test Code
@Test
public void POST_리퀘스트바디_기본패턴() throws Exception {
    mockMvc.perform(post("/requestBody")
                    .contentType(MediaType.APPLICATION_JSON_UTF8)
                    .content("{\"name\":\"yangs\", \"ldt\":\"2018-12-15T10:11:22\"}"))
            .andExpect(status().isOk())
            .andDo(print());
}

yyyy-MM-ddTHH:mm:ss 패턴이 아니라면 @JsonFormat을 VO에 지정해줘야 한다.

• @JsonFormat은 스프링부트에서 json 파싱에 사용되는 기본 라이브러리인 Jackson에 포함되어있다.
• 예를들어 날짜와 시간사이에 공백이 들어간 yyyy-MM-dd HH:mm:ss 패턴으로 데이터를 보내는 경우
  @JsonFormat pattern 속성에 동일하게 세팅만 되면 정상적으로 파싱 및 바인딩 된다.

// VO
public class TestVo {
    @JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd HH:mm:ss", timezone = "Asia/Seoul")
    private LocalDateTime ldt;
    private String name;
}

// Controller
@RequestMapping(path = "/requestBody", method = RequestMethod.POST)
@ResponseBody
public String rbPost(@RequestBody TestVo dto){
    System.out.println("dto : " + dto);
      return "good";
}

// Test Code
@Test
public void POST_리퀘스트바디_기본패턴() throws Exception {
    mockMvc.perform(post("/requestBody")
                    .contentType(MediaType.APPLICATION_JSON_UTF8)
                    .content("{\"name\":\"yangs\", \"ldt\":\"2018-12-15 10:11:22\"}"))
            .andExpect(status().isOk())
            .andDo(print());
}

스프링 라이브러리의 @DateTimeFormat 으로 패턴을 준 경우는 제대로 동작하지 않고 오류난다.

• Jackson에서 json파싱시 @DateTimeFormat을 바라보지 않는다.(Jackson 라이브러리 내에서 파싱하므로 스프링의 @DateTimeFormat을 알지 못한다.)

// VO
public class TestVo {
  @DateTimeFormat(pattern = "yyyy/MM/dd HH:mm:ss")
  private LocalDateTime ldt;
  private String name;
}

// Controller
@RequestMapping(path = "/requestBody", method = RequestMethod.POST)
@ResponseBody
public String rbPost(@RequestBody TestVo dto){
  System.out.println("dto : " + dto);
  return "good";
}

// Test Code
@Test
public void POST_리퀘스트바디_기본패턴() throws Exception {
  mockMvc.perform(post("/requestBody")
                  .contentType(MediaType.APPLICATION_JSON_UTF8)
                  .content("{\"name\":\"yangs\", \"ldt\":\"2018-12-15 10:11:22\"}"))
          .andExpect(status().isOk())
          .andDo(print());
}

RequestBody로 Json을 바인딩 받을때는 @JsonFormat을 사용한다!

RequestParam

• yyyy-MM-ddTHH:mm:ss 패턴에 아무런 VO설정이 없으면 String을 LocalDateTime으로 변경할 수 없다는 메시지로 실패한다.(RequestBody는 아무런 설정없이 동작했다.)
• Json과 관련이 없기 때문에 @JsonFormat을 지정해도 위 케이스와 같은 오류로 실패한다.

// VO
public class TestVo {
    private LocalDateTime ldt;
    private String name;
}

// Controller
@RequestMapping(path = "/requestParam", method = RequestMethod.GET)
@ResponseBody
public String rpGet(@RequestParam TestVo dto){
    System.out.println("dto : " + dto);
    return "good";
}

// Test Code
@Test
public void POST_리퀘스트파람_기본패턴() throws Exception {
    mockMvc.perform(get("/ma?name=yangs&ldt=2020-03-18T18:25:40"))
            .andExpect(status().isOk())
            .andDo(print());
}

• yyyy-MM-ddTHH:mm:ss 패턴은 @DateTimeFormat에서 T 문자열 때문에 오류난다.

// VO
public class TestVo {
    @DateTimeFormat(pattern = "yyyy-MM-ddTHH:mm:ss")
    private LocalDateTime ldt;
    private String name;
}

// Controller
@RequestMapping(path = "/requestParam", method = RequestMethod.GET)
@ResponseBody
public String rpGet(@RequestParam TestVo dto){
    System.out.println("dto : " + dto);
    return "good";
}

// Test Code
@Test
public void POST_리퀘스트파람_기본패턴() throws Exception {
    mockMvc.perform(get("/ma?name=yangs&ldt=2020-03-18T18:25:40"))
            .andExpect(status().isOk())
            .andDo(print());
}

• T대신 공백을 추가한 yyyy-MM-dd HH:mm:ss 패턴으로 @DateTimeFormat을 지정하면 정상 바인딩된다.
  yyyy/MM/dd HH-mm-ss, yyyyMMddHHmmss, dd-MM-yyyy HH:mm:ss 패턴들도 @DateTimeFormat을 지정시 정상 바인딩된다.

// VO
public class TestVo {
    @DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss")
    private LocalDateTime ldt;
    private String name;
}

// Controller
@RequestMapping(path = "/requestParam", method = RequestMethod.GET)
@ResponseBody
public String rpGet(@RequestParam TestVo dto){
    System.out.println("dto : " + dto);
    return "good";
}

// Test Code
@Test
public void POST_리퀘스트파람_기본패턴() throws Exception {
    mockMvc.perform(get("/ma?name=yangs&ldt=2020-03-18 18:25:40"))
            .andExpect(status().isOk())
            .andDo(print());
}

RequestParam으로 바인딩 받을때는 @DateTimeFormat을 사용하되 T문자열을 제외한 패턴을 사용한다.

ModelAttribute

• RequestParam과 같은 결과가 나온다. @DateTimeFormat 설정시에만 정상 바인딩 된다.(yyyy-MM-ddTHH:mm:ss 는 안된다.)

// VO
public class TestVo {
    @DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss")
    private LocalDateTime ldt;
    private String name;
}

// Controller
@RequestMapping(path = "/modelAttribute", method = RequestMethod.POST)
@ResponseBody
public String maPost(@ModelAttribute TestVo dto){
    System.out.println("dto : " + dto);
    return "good";
}

// Test Code
@Test
public void POST_모델어트리뷰트() throws Exception {
    mockMvc.perform(post("/modelAttribute")
                        .param("name", "yangs")
                        .param("ldt", "2020-03-18 18:25:40")
                        .contentType(MediaType.APPLICATION_FORM_URLENCODED))
            .andExpect(status().isOk())
            .andDo(print());
}

ResponseBody

• Jackson이 JSON으로 VO를 직렬화 해야하므로 @JsonFormat 설정을 따라간다.
• 만일 VO에 아무런 애너테이션도 없다면 yyyy-MM-ddTHH:mm:ss 패턴의 스트링 값으로 직렬화되며, @DateTimeFormat 설정이 있어도 무시하고 yyyy-MM-ddTHH:mm:ss 패턴으로 직렬화한다. 둘 다 설정된 경우는 당연히 @JsonFormat을 따라간다.

// VO
public class TestVo {
    @JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "yyyyMMddHHmmss", timezone = "Asia/Seoul")
    @DateTimeFormat(pattern = "yyyy/MM/dd HH:mm:ss")
    private LocalDateTime ldt;
    private String name;

    public TestVo(String name, LocalDateTime ldt) {
        this.name = name;
        this.ldt = ldt;
    }
}

// Controller
@RequestMapping(path = "/responseBody", method = RequestMethod.GET)
@ResponseBody
public TestVo rbGet(){
    return new TestVo("yangs", LocalDateTime.now());
}

// Test Code
@Test
public void GET_리스폰스바디() throws Exception {
    mockMvc.perform(get("/responseBody")
                    .accept(MediaType.APPLICATION_JSON))
            .andExpect(status().isOk())
            .andDo(print());
}

정리

@RequestBody로 JSON데이터를 LocalDateTime 변수에 바인딩하고 싶다면? 설정없이 yyyy-MM-ddTHH:mm:ss 로 JSON데이터를 보낸다. 또는 LocalDateTime 변수에 @JsonFormat을 지정한다.

• 테스트 데이터의 패턴이 yyyy-MM-ddTHH:mm:ss 면서, VO 변수에 설정이 없는경우 : 성공
• 테스트 데이터의 패턴이 yyyy-MM-ddTHH:mm:ss 이 아니면서, VO 변수에 @JsonFormat 설정인 경우 : 성공
• 테스트 데이터의 패턴이 yyyy-MM-ddTHH:mm:ss 이 아니면서, VO 변수에 @DateTimeFormat 설정인 경우 : 실패

@RequestParam, @ModelAttribute, @Pathvariable로 LocalDateTime 변수에 바인딩하고 싶다면? LocalDateTime 변수에 @DateTimeFormat을 지정한다.

• 테스트 데이터의 패턴이 yyyy-MM-ddTHH:mm:ss 면서, VO 변수에 설정이 없는경우 : 실패
• 테스트 데이터의 패턴이 yyyy-MM-ddTHH:mm:ss 이 아니면서, VO 변수에 @JsonFormat 설정인 경우 : 실패
• 테스트 데이터의 패턴이 yyyy-MM-ddTHH:mm:ss 면서, VO 변수에 @DateTimeFormat 설정인 경우 : 실패
• 테스트 데이터의 패턴이 yyyy-MM-dd HH:mm:ss, yyyy/MM/dd HH-mm-ss, yyyyMMddHHmmss, dd-MM-yyyy HH:mm:ss 면서, VO 변수에 @DateTimeFormat 설정인 경우 : 성공

@ResponseBody로 VO의 LocalDateTime 변수를 JSON 데이터로 보내고 싶다면? 설정없이 yyyy-MM-ddTHH:mm:ss 으로 데이터를 보낸다. 또는 LocalDateTime 변수에 @JsonFormat을 지정한다.

• VO에 아무런 설정이 없는경우 : yyyy-MM-ddTHH:mm:ss 패턴의 스트링 반환
• VO의 LocalDateTime 변수에 @DateTimeFormat 설정인 경우 : 설정이 무시되며 yyyy-MM-ddTHH:mm:ss 패턴의 스트링 반환
• VO의 LocalDateTime 변수에 @JsonFormat 설정인 경우 : 설정된 패턴으로 스트링 반환(yyyy-MM-dd HH:mm:ss, yyyy/MM/dd HH-mm-ss, yyyyMMddHHmmss, dd-MM-yyyy HH:mm:ss)

읽어주셔서 감사합니다. 도움이 되셨다면 광고 클릭 부탁드립니다.

모두 힘내세요! : )

오류발생

새로운 Controller를 테스트하기 위해 테스트 소스를 작성하고 WebMvc와 관련된 빈만 등록해 테스트 하고자 했다.
제공되는 SliceTest 애노테이션인 @WebMvcTest를 테스트클래스에 마킹하고 실행했으나 초기화 단계에서 Exception이 발생하였다.

org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'entityManagerFactory' available

원인

@WebMvcTest로 WebMvc와 관련된 빈만 등록된 상태에서 메인클래스에 마킹한 @EnableJpaRepositories이 JPA와 관련된 빈을 찾아 작업을 하려할 때 오류가 발생하였다.

해결

QueryLookupStrategy 설정을 위해 메인클래스에 @EnableJpaRepositories를 마킹했으나, 굳이 필요한 설정은 아니므로 지우고 테스트를 실행하였다.(그저 학습의 이유로 디폴트 전략을 명시적으로 설정하였다.)
만일 필요한 옵션이라면 @EnableJpaRepositories를 통해서 하지않고 다른 방법으로 옵션을 줬어야 했을것이다.

@SpringBootApplication
//@EnableJpaRepositories(queryLookupStrategy = QueryLookupStrategy.Key.CREATE_IF_NOT_FOUND)
public class App {
    public static void main(String[] args) {
        SpringApplication app = new SpringApplication(App.class);
        app.setWebApplicationType(WebApplicationType.SERVLET);
        app.run(args);
    }
}

참고

링크 : github.com/spring-projects/spring-boot/issues/6844 

By using @EnableJpaRepositories you are explicitly telling Spring Boot’s auto-configuration to back off and that you’ll handle Spring Data yourself.
I think what’s happening is that @WebMvcTest is turning off JPA (i.e. not finding your @Entity classes) but @EnableJpaRepositories is still active so it complains that it can’t find any JPA models.

스프링부트의 Log 라이브러리

스프링부트는 Java Util Logging, Log4J2, Logback 이렇게 3가지에 대해 기본 설정을 제공하고 있다. spring-boot-starter-logging 의존성을 추가하면 로그관련 라이브러리들이 추가되는 것을 볼 수 있다.

이 중에서 스프링부트는 기본으로 Logback을 사용하며 자동으로 이루어지는 설정은 org.springframework.boot.logging.DefaultLogbackConfiguration 파일을 참고한다.
기본설정으로 아래와 같이 시간-로그레벨-프로세스ID-구분자-쓰레드명-로거명-로그내용 포맷이 출력된다.

디폴트 설정에서 변경을 원한다면 프로퍼티 설정파일에서 logging으로 시작하는 옵션을 지정하거나 별도의 로그설정파일(logback.xml 등)을 사용하여 디폴트 설정을 오버라이드 한다.

Log Level

스프링부트의 기본설정은 INFO 레벨 이상인 로그만 보여준다. 만일 상세한 로그가 보고 싶다면 debug모드로 어플리케이션을 기동하던지 출력되는 로그레벨을 프로퍼티에서 조정한다.

• 디버그 모드로 기동
  • jar파일 실행시 --debug 옵션을 부여한다.
  • 프로퍼티 설정파일(application.properties)에 debug=true을 추가한다.
• 어플리케이션의 출력로그 레벨을 조정
  • logging.level을 prefix로 하는 프로퍼티를 추가한다.
  • logging.level.<logger-name>=<level>
  • logging.level.com.yang.wind.mapper=TRACE : com.yang.wind.mapper 패키지 이하의 로그레벨을 TRACE로 한다.
  • logging.level.root=INFO : root 이하 모든 패키지의 로그레벨을 INFO로 한다.

Log Color

만약 ANSI를 지원하는 터미널을 사용한다면 프로퍼티 설정파일에 spring.output.ansi.enabled=detect 또는 always 옵션을 줘서 로그를 컬러풀하게 출력할 수 있다.

Log 파일출력

기본적으로 아무설정이 없다면 콘솔은 출력하지만 로그파일은 작성되지 않는다. 파일로 로그를 출력하고자 한다면 프로퍼티 설정파일에 logging.file.name 과 logging.file.path 프로퍼티를 추가한다.
name과 path 두 설정을 모두 지정할 경우에는 함께 동작하지 않는다. logback-spring.xml 과 같이 별도의 파일로 설정을 해줘야 할 듯 싶다.
프로퍼티 지정에 따른 동작방식은 아래를 참고하자.

Log Group

특정 로거들을 그룹핑하여 설정을 동일하게 변경이 가능하다. 예를들어 Tomcat에 관련된 로거들을 동시에 설정변경 하고자 한다면 각자의 패키지로 설정을 변경하기 보다는 그룹을 지정하여 간편하게 변경할 수 있다.

프로퍼티 설정파일에서 tomcat이라는 그룹을 생성하고 설정을 변경한다. 

• logging.group.tomcat=org.apache.catalina, org.apache.coyote, org.apache.tomcat
• logging.level.tomcat=TRACE

또한 스프링부트는 미리 설정된 그룹을 제공하기 때문에 편리하게 로그레벨 설정이 가능하다.

Custom Log 설정

설정한 로그시스템에 따라 아래의 파일이 로드되어 환경이 구성된다. 디테일한 커스텀 설정을 위해서는 로그시스템 별로 아래 xml 파일이나 properties 파일을 작성한다.

스프링부트에서 테스트는 일단 spring-boot-starter-test 의존성을 추가하고, @SpringBootTest가 마킹된 테스트 클래스를 작성한다. 이때 컨트롤러에 대한 테스트라면 MockMvc나 내장톰캣을 구동하여 테스트를 진행할 수 있으며, @WebMvcTest 등을 활용하여 특정 레이어만 테스트할 수도 있다.

하나씩 알아본다.

spring-boot-starter-test 스프링부트에서 테스트를 위해 추가하는 의존성

스프링부트에서는 테스트를 위해 제공하는 라이브러리가 있으며 코어 라이브러리와 Auto-Configuration을 포함하는 Starter(라이브러리 및 자동설정을 포함)를 제공한다. Stater 안에는 Spring 테스트모듈을 포함하여 JUnit, Jupiter, AssertJ, Hamcrest 등의 테스트시 유용한 라이브러리가 포함되어 있다.

메이븐을 사용하다면 아래와 같이 pom.xml에 spring-boot-starter-test를 다음과 같이 추가한다.

Test Class 작성

스프링부트 어플리케이션 테스트를 작성할 클래스에는 테스트의 성격에 따라서 스프링에서 제공하는 애노테이션을 조합하여 마킹할 수 있다.
가장 기본적으로는 @SpringBootTest가 있는데, 이는 스프링의 @ContextConfiguration 애노테이션을 대체하면서 몇 가지 기능을 제공한다. (스프링에서는 테스트를 위한 환경설정을 위해 @ContextConfiguration를 사용한다.)

아래는 기본적인 스프링부트 테스트 클래스이다.

Junit의 스프링 테스트를 위해 @Runwith가 마킹되어 있고, @SpringBootTest는 테스트를 위한 환경설정 및 부가기능을 제공한다. 각 @Test 메서드마다 단위 테스트를 작성한다.

@RunWith(SpringRunner.class)
@SpringBootTest // 테스트를 위한 환경설정 및 부가기능을 제공한다.
public class SampleTest {

    @Test
    public void test1(){
        //
    }

    @Test
    public void test2(){
        //
    }
}

@SpringBootTest의 기능

• 기본 ContextLoader로써 SpringBootContextLoader를 사용한다.
• 자동으로 @SpringBootConfiguration을 찾는다. @SpringBootConfiguration은 @SpringBootApplication(메인 클래스) 안에 있다.
• 커스텀 Environment 프로퍼티를 정의할 수 있다.
• 어플리케이션 구동 시 설정하는 application argument를 테스트 프로그램에서 정의할 수 있다.
  @SpringBootTest(args="--app.test=one")
• WebEnvironment를 지정할 수 있다.
  • WebEnvironment.MOCK : 아무런 설정이 없을 시 적용되는 디폴트 설정이다. mock 서블릿 환경으로 내장톰캣이 구동되지 않는다.(브라우저에서 접속되지 않는다.)
  • WebEnvironment.RANDOM_PORT : 스프링부트를 직접 구동시킨 것처럼 내장톰캣이 구동되나 랜덤포트로 구동된다.
  • WebEnvironment.DEFINED_PORT : 정의된 포트로 내장톰캣이 구동된다.
  • WebEnvironment.NONE : WebApplicationType.NONE으로 구동된다.
• 테스트를 위한 TestRestTemplate 빈과 WebTestClient 빈을 등록할 수 있다.
  만일 WebEnvironment.MOCK 이라면 TestRestTemplate과 WebTestClient빈은 등록되지 않는다. 실제 내장톰캣이 구동되지 않으므로 사용할 여지가 없고 어플리케이션에 요청을 보내고 싶다면 MockMvc로 테스트하면 되기 때문이다.

WebEnvironment 설정에서 디폴트 값이 MOCK 이므로 내장톰캣이 구동되지 않고 테스트가 수행되는 것에 유의한다.

@AutoConfigureMockMvc

디폴트 설정이 서버가 실행되지 않고 Mock 환경에서 진행되므로 컨트롤러처럼 엔드포인트가 있는 테스트를 진행할 때는 MockMvc를 활용한다.
MockMvc는 가상의 클라이언트로 어플리케이션에 요청을 날리는 역할을 한다. MockMvc를 생성하는 방법에는 여러 가지 있지만 테스트클래스에 @AutoConfigureMockMvc을 마킹하고 주입받는 것이 간단하다.

MockMvc를 사용하여 mock 환경에서 컨트롤러를 테스트하는 코드이다.

@Controller
public class SampleController { // 테스트 대상의 컨트롤러
    @GetMapping("/sample")
    @ResponseBody
    public String sample(){
        return "sample's return";
    }
}

import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.*;
import static org.springframework.test.web.servlet.result.MockMvcResultHandlers.*;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*;

@RunWith(SpringRunner.class)
@SpringBootTest
@AutoConfigureMockMvc // MockMvc를 생성한다.
public class SampleTest {
    @Autowired
    MockMvc mockMvc; // 생성된 MockMvc 빈을 주입받아 테스트에 사용한다.

    @Test
    public void sampleController_Test() throws Exception {
        mockMvc.perform(get("/sample"))
                .andExpect(handler().handlerType(SampleController.class))
                .andExpect(handler().methodName("sample"))
                .andExpect(status().isOk())
                .andExpect(content().string("sample's return"))
                .andDo(print());
    }

}

요청을 받는 클래스나 메서드명부터 결과 상태코드, 리턴값 등 다양한 검증이 가능하다. 

내장톰캣 구동 테스트

Mock서블릿 환경이 아닌 내장톰캣을 구동하여 테스트를 하기 위해서는 @SpringBootTest에 WebEnvironment를 설정한다.

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)

내장 톰캣으로 구동이 되면 MockMvc 로는 테스트할 수 없으니 테스트를 위한 HTTP 클라이언트를 사용해야 한다. 여기서 사용할 수 있는 클라이언트가 TestRestTemplate다. 여기에 더해서 여러 레이어 간의 동작을 보는 통합 테스트가 아니라 단위 테스트인 경우에는 MockBean을 실제 빈 대신에 주입한 고립 테스트가 가능하다.

아래 컨트롤러를 테스트해보자.

@Controller
public class SampleController {
    @Autowired
    SampleService service; // 테스트대상(SampleController)이 다른 빈에 의존성을 가진다.

    @GetMapping("/sample")
    @ResponseBody
    public String sample(){
        return service.service(); // 서비스빈 호출
    }
}

SampleService가 어떻게 동작하는지 상관없이 SampleController의 구현을 대상으로 하는 테스트라면 @MockBean을 활용하여 실제 빈을 대체할 수 있다.

import static org.mockito.Mockito.when;

@RunWith(SpringRunner.class)
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class SampleTest {
    @Autowired
    TestRestTemplate testRestTemplate;

    @MockBean
    SampleService mockSampleService;

    @Test
    public void sampleController_mockService_Test() throws Exception {
        // SampleService의 리턴을 사전에 정의한다.
                when(mockSampleService.service()).thenReturn("mock service");

        String result = testRestTemplate.getForObject("/sample", String.class);
        Assert.assertEquals(result, "mock service");
    }
}

Mock 서블릿 환경이 아닌 실제 내장톰캣이 랜덤포트로 구동됐으므로MockMvc는 사용할 수 없다. 그 대신 주입받은 테스트용 클라이언트인 TestRestTemplate를 활용하여 테스트 요청을 보내고 정의한 리턴 값을 확인한다.

Slice Test

@SpringBootTest는 자동 설정을 포함한 프로젝트의 전체 빈을 모두 등록하여 테스트한다.(그러므로 무겁다.) 만일 컨트롤러처럼 MVC만 테스트하고 싶거나, JPA만 테스트하고 싶은 경우 특정 레이어의 빈만 등록하여 가볍게 테스트할 수 있도록 애노테이션을 제공하고 있다.

@WebMvcTest, @WebFluxTest, @DataJpaTest 등 제공되는 애노테이션들이 있지만 @WebMvcTest만 살펴본다.

@WebMvcTest

스프링 MVC 컨트롤러에 관련된 환경구성만 진행하므로 @Controller, @ControllerAdvice, @JsonComponent, Converter, GenericConverter, Filter, HandlerInterceptor, WebMvcConfigurer, 그리고 HandlerMethodArgumentResolver 만 빈으로 등록된다.

다른 의존성이 있다면 테스트에서 빈등록 위해 명시해주거나 MockBean으로 대체해야 한다.

@RunWith(SpringRunner.class)
@WebMvcTest(SampleController.class) // 테스트대상 클래스만 빈으로 등록한다.
public class SampleTest {
    @MockBean
    SampleService mockSampleService;

    @Autowired
    MockMvc mockMvc;

    @Test
    public void sampleController_Test() throws Exception {
        // SampleService의 리턴을 사전에 정의한다.
        when(mockSampleService.service()).thenReturn("mock service");

        mockMvc.perform(get("/sample"))
                .andExpect(handler().handlerType(SampleController.class))
                .andExpect(handler().methodName("sample"))
                .andExpect(status().isOk())
                .andExpect(content().string("mock service"))
                .andDo(print());
    }
}

요약하면

• 스프링부트에서는 테스트를 위해 starter 라이브러리를 제공하고 있다.
• classpath에 starter 의존성만 추가하면 자동 설정까지 완료된다.
• 스프링부트 테스트에서는 @SpringBootTest를 활용하여 테스트를 위한 초기설정이나 환경설정을 추가/변경 할 수 있다.
• 테스트하고자 하는 대상이 다른 빈을 참조하고 있다면 Mock 빈의 사용을 고려하자.
• @SpringBootTest와 다르게 일부 레이어 테스트를 위한 @WebMvcTest 등을 제공하고 있다.

스프링에서는 Profile을 지정하여 어플리케이션의 구성(Configuration)을 Profile별로 가져갈 수 있도록 한다. 즉, 같은 소스코드를 두고 로컬환경, 개발환경, 운영환경별로 다른 구성(DB 접속정보, 업로드 파일의 저장위치 등)으로 실행할 수 있다.

@Profile

다르게 가져갈 구성은 @Component, @Configuration, @ConfigurationProperties 애노테이션에 @Profile을 마킹하여 지정하고, 어플리케이션 실행시 spring.profiles.active 프로퍼티로 프로파일을 지정하면 해당 프로파일이 적용된 빈만 등록된다.

아래는 test 프로파일을 적용해본 예시이다. @Component를 마킹하여 빈으로 등록될 클래스에 @Profile을 마킹했다. 이러면 정의한 프로파일에서만 빈으로 등록된다.

@Component
@Profile("test") // 이 클래스는 [test]프로파일에서만 빈으로 등록된다.
public class TestBean {
}

@Component
public class Sample implements ApplicationRunner {
    @Autowired(required = false)
    TestBean testBean;

    @Override
    public void run(ApplicationArguments args) throws Exception {
        System.out.println("=====================================================");
        System.out.println("test 프로파일에서만 등록되는 빈 : " + testBean);
        System.out.println("=====================================================");
    }
}

테스트시 --spring.profiles.active=test 옵션을 주고 실행시 다음과 같이 콘솔에 남으며 TestBean 빈이 null 값이 아니라 등록 되었음을 확인할 수 있다.

만일 --spring.profiles.active=test 옵션을 빼고 실행하여 디폴트 프로파일로 실행하거나 --spring.profiles.active=dev 처럼 다른 프로파일을 지정하면 null 값으로 콘솔에 남는다.

Profile - Property File

스프링부트는 활성화 된 프로파일에 따라서 지정된 프로퍼티 파일을 읽는다.
즉 어떠한 프로파일도 활성화 하지 않으면 디폴트 프로퍼티 파일로 application.properties를 읽지만 test 프로파일을 활성화 하면 프로퍼티 파일로 application-test.properties를 읽어온다. 하지만 application-test.properties만 읽는것이 아니라 application.properties 파일도 같이 읽으며 중복된 값이 profile이 정의된 파일로 오버라이드 된다.

• XXX 프로파일 활성화시 설정파일 : application.properties, application.yml, application-XXX.properties, application-XXX.yml

프로파일에 따라 어떻게 설정파일을 읽는지 알기위해 간단한 테스트를 해본다.

3개의 프로퍼티 파일을 작성 후 활성화한 프로파일에 따라 어떻게 값이 오버라이드 되는지 알아본다.

• profile-common.name는 모든 프로퍼티 파일이 공통으로 가진 프로퍼티이고, 각 파일마다 개별로 가지고있는 프로퍼티도 있다.
• test 프로파일을 활성화하고 어플리케이션을 기동하면 공통속성인 profile-common.name은 프로파일 프로퍼티 파일(application-test.yml)이 나머지를 오버라이드하여 testnameCommon이 값이 된다.
• application-test.yml 뿐만 아니라 디폴트 프로파일 파일인 application.yml 또한 읽으므로 defaultonly.name은 defaultname이 값이 된다.
• 활성화 되지 않은 application-dev.yml 파일의 프로퍼티들은 읽지 않는다.

간단한 ApplicationRunner를 작성하여 프로퍼티 값을 콘솔에 찍어본다.

@Component
public class Sample implements ApplicationRunner {

    @Autowired
    Environment env;

    @Override
    public void run(ApplicationArguments args) throws Exception {
        System.out.println("=====================================================");
        System.out.println("spring.profiles.active : " + args.getOptionValues("spring.profiles.active"));
        System.out.println("Enviroment's Active Profile : " + Arrays.toString(env.getActiveProfiles()));
        System.out.println("defaultonly.name : " + env.getProperty("devonly.name"));
        System.out.println("testonly.name : " + env.getProperty("testonly.name"));
        System.out.println("devonly.name : " + env.getProperty("devonly.name"));
        System.out.println("profile-common.name : " + env.getProperty("profile-common.name"));
        System.out.println("=====================================================");
    }
}

외부설정(Externalized Configuration)

스프링부트는 외부설정을 통해 같은 소스코드로 각기 다른 환경에서 실행될 수 있도록 해준다.
코드의 외부설정으로는 properties 파일, YAML 파일, 환경변수, 커맨드라인 아규먼트 등으로 설정이 가능하다.

외부설정(Property)은 다음과 같이 소스코드에서 사용할 수 있다.

• @Value : 소스코드에서 바로 프로퍼티에 주입받아 사용
• Environment : 외부설정이 바인딩 된 Environment 를 주입받아 사용
• @ConfigurationProperties : 외부설정이 바인딩 될 Bean(객체)을 생성하여 사용

외부설정을 할 수 있는 방법이 여러 가지가 있으므로 이들 사이에 우선순위도 존재한다.
같은 프로퍼티를 여기저기서 설정했다면 정의된 우선순위에 따라서 가장 높은 우선순위가 나머지를 오버라이드 한다.

스프링부트 공식문서에 소개된 우선순위는 17가지이므로 우선순위에 대한 개념만 알고 넘어가며 상황에 따라 찾아보면 될 듯하다.
기본적인 classpath 이하에 application.properties 파일을 두는 것은 우선순위가 15위로 하위권이다. 당연히 3순위인 Command line argument를 부여하면 오버라이드 된다.
예를 들어application.properties에 foo = bar1로 작성하고 java -jar myproject.jar --foo=bar2 로 애플리케이션을 실행하면 애플리케이션에서 foo에 맵핑된 프로퍼티 값은 ‘bar2’가 된다.

- 외부설정 및 우선순위에 대한 스프링 문서 :

https://docs.spring.io/spring-boot/docs/2.2.2.RELEASE/reference/html/spring-boot-features.html#boot-features-external-config

외부 프로퍼티 파일

여러 가지 방법으로 외부설정이 가능하다 하더라도 가장 많이 사용할 외부설정 방식은 프로퍼티 파일일 것이다.
주로 classpath:/application.properties 경로에 설정파일을 두고 사용하고 있지만 여러 경로에 두는 것이 가능하다.

프로퍼티 파일의 위치에 따라서 정의된 우선순위가 있다. 마찬가지로 같은 프로퍼티가 여러 파일에 정의되어 있다면 우선순위가 높은 경로에 있는 파일이 오버라이드 한다.

공식문서에서 소개하는 우선순위이다. classpath 바로 이하에 두는 것은 우선순위가 제일 낮은 6위이다. classpath 이하에 디폴트 설정 파일을 두고 필요에 따라 실제 프로퍼티 값을 가진 파일을 상위 우선순위 위치에 두는 전략을 생각해볼 수 있다.

1. file:./custom-config/
2. classpath:custom-config/
3. file:./config/
4. file:./
5. classpath:/config/
6. classpath:/

위 경로 중에custom-config 디렉터리는 개발자가 직접 설정이 가능한 경로라는 의미이다.
spring.config.name와 spring.config.location 프로퍼티로 커스텀한 파일경로를 지정한다. 프로퍼티 파일경로에 대한 설정은 기동시 이른 시점에 결정되어야 하므로 OS환경변수나 시스템 프로퍼티 또는 커맨드라인 아규먼트로 지정해줘야 한다.
아래는 커맨드라인 아규먼트로 지정한 예시이다. 경로(파일도 가능)는 컴마(,)를 구분자로 여러 개를 지정할 수 있다.

spring.config.name 프로퍼티로 파일명만 지정한다.

$ java -jar myproject.jar --spring.config.name=myproject

spring.config.location 프로퍼티로 경로와 파일명까지 지정한다.

$ java -jar myproject.jar --spring.config.location=classpath:/default.properties,classpath:/override.properties

요약하면

• 스프링부트는 코드 밖에서 외부 프로퍼티 설정이 가능하다.
• 외부는 properties 파일, YAML 파일, 환경변수, 커맨드라인 아규먼트 등을 말하며 이들 사이에는 우선순위가 있어 프로퍼티 값이 오버라이드 된다.
• 외부설정 중 많이 쓰이는 ‘파일 외부설정’은 파일이 위치하는 경로에 따라 우선순위가 있어 프로퍼티 값이 오버라이드 된다.
• 파일 외부설정시 디폴트 파일명, 경로 외에 spring.config.name, spring.config.location 프로퍼티 설정으로 커스텀한 파일명 또는 경로를 지정할 수 있다.

Property Binding

스프링부트 프로젝트를 생성하면 외부 프로퍼티 설정파일을 만들게 된다.(application.yml, application.properties ...) 여기 정의한 키-값들이 결국 어플리케이션이 기동되면서 클래스로 바인딩 되는데 이 과정에 대해 알아본다.

먼저 클래스에서 외부 프로퍼티 값들을 가져오는 방식을 살펴보자. 아래 3가지를 이용할 수 있다.

• @Value : 소스코드에서 바로 프로퍼티에 주입받아 사용
• Environment : 외부설정이 바인딩 된 Environment 빈을 주입받아 사용
• @ConfigurationProperties : 외부설정이 바인딩 될 Bean(객체)을 생성하여 사용

가장 빈번하게 사용하는 방식은 @Value("${property}") 방식일 듯 싶지만 불러올 프로퍼티의 갯수가 많거나, 계층형의 구조를 가지고 있는 경우 등에는 적절하지 않다. 또한 프로퍼티명이나 타입을 직접 입력해야 하므로 오류에 대한 여지도 있다. @Value와 Environment 빈에 대한 예시는 아래와 같다.

application.properties에 다음과 같이 프로퍼티 키-값 정의 : yangs.name=brand

@Component
public class SimpleRunner implements ApplicationRunner {
    @Autowired
    Environment environment; // Environment 타입의 빈 주입

    @Value("${yangs.name}") // ${}내부에 작성된 프로퍼티키에 해당하는 값을 세팅
    String name1; 

    @Override
    public void run(ApplicationArguments args) throws Exception {
        System.out.println("Value 애노테이션의 yangs.name : " + name1);

        String name2 = environment.getProperty("yangs.name");
        System.out.println("Environment bean의 yangs.name : " + name2);
    }
}

간단한 몇 개의 값이라면 @Value를 사용하여 바인딩할 수 있지만, 검증이나 Type-safe, 계층형 구조 등을 처리할 수 있는 @ConfigurationProperties를 이용한 방법이 있다,

application.yml의 예시와 이 값을 @ConfigurationProperties를 어떻게 사용하여 바인딩 하는지 예제로 살펴본다.

application.yml 예시

일반적으로 프로퍼티명은 아래 is-main-tester처럼 소문자와 대쉬(-)를 구분자로 하는 명칭이 권장된다.
프로퍼티명 앞의 대쉬(-)는 리스트형을 나타낼때 사용한다.

@ConfigurationProperties(prefix = “test”) 로 프로퍼티클래스에 값 바인딩하기

프로퍼티가 맵핑될 클래스(아래의 TesterProperties)를 작성하고 @ConfigurationProperties을 마킹한다. 이 클래스는 프로퍼티값이 맵핑될 클래스라는 의미로 애노테이션에는 프로퍼티명의 prefix(아래의 prefix = "test")를 지정할 수 있다.
프로퍼티 파일에서 리스트형으로 작성한 sub-testers를 맵핑할 수 있도록 List<Subster> subTesters 로 선언한 것을 볼 수 있고,
작성된 위의 프로퍼티 파일은 kebab case(- 가 구분자)로 작성하였으나 클래스 변수명은 camel case이다.
스프링부트에서는 프로퍼티명의 camel case, kebab case, underscore notation 간의 변환을 모두 지원한다.
subTesters - sub-testers - sub_testers 모두 변환하여 바인딩이 가능하다.

import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;

import java.util.ArrayList;
import java.util.List;

// 읽어들인 프로퍼티 중 해당 prefix의 프로퍼티값을 바인딩한다.
@ConfigurationProperties(prefix = "test")
public class TesterProperties {
    private String name;
    private int cnt;
    private boolean isMainTester;
    private List<SubTester> subTesters = new ArrayList<>();

    // Getter, Setter, ToString 생략
    
    static class SubTester {
        private String name;
        private int cnt;
        private boolean isMainTester;
            
        // Getter, Setter, ToString 생략
    }
}

@EnableConfigurationProperties(TesterProperties.class)로 프로퍼티클래스 사용하기

바인딩이 완료된 TesterProperties를 빈으로 등록하여 사용하기 위해 @EnableConfigurationProperties를 마킹한다.
주로 프로퍼티 값을 사용할 @Configuration 파일에 마킹하며, @ConfigurationProperties가 마킹된 클래스를 빈으로 등록해주는 역할이다. 만일 프로퍼티 클래스가 다수라면 @ConfigurationPropertiesScan({"base.package1", "base.package2"}) 으로 여러 패키지를 스캔하여 등록할 수도 있다.
프로퍼티가 제대로 바인딩 됬는지 테스트를 위해 ApplicationRunner를 작성 후 콘솔로그를 찍어본다.

import org.springframework.boot.ApplicationArguments;
import org.springframework.boot.ApplicationRunner;
import org.springframework.boot.context.properties.EnableConfigurationProperties;
import org.springframework.stereotype.Component;

@Component
@EnableConfigurationProperties(TesterProperties.class)
public class PropertyRunner implements ApplicationRunner {
    private final TesterProperties testerProperties; // 값이 바인딩된 빈이 의존성 주입된다.

    public PropertyRunner(TesterProperties testerProperties) {
        this.testerProperties = testerProperties;
    }

    @Override
    public void run(ApplicationArguments args) throws Exception {
        // 바인딩이 제대로 되었는지 콘솔 출력
        System.out.println("=================================");
        System.out.println("TesterProperties : " + testerProperties);
        System.out.println("=================================");
    }
}

String, int, boolean 및 List 형까지 바인딩이 제대로 된 것을 확인할 수 있다. 혹여 바인딩시 Validation을 하고 싶다면 아래와 같이 스프링의 @Validated 와 JSR-303에 정의된 javax.validation 애노테이션을 사용할 수 있다.

@ConfigurationProperties(prefix = "test")
@Validated // 검증대상임을 표시
public class TesterProperties {
    @NotNull
    private String name;
    @Max(90)
    private int cnt;
    private boolean isMainTester;
    @Valid // 내부 프로퍼티에 검증이 적용되려면 @Valid를 마킹한다.
    private List<SubTester> subTesters = new ArrayList<>();

    static class SubTester {
        @NotNull
        private String name;
        @Min(20)
        private int cnt;
        private boolean isMainTester;
    }
    
    // Getter, Setter, ToString 생략
}

요약하면

• 외부에서 설정된 프로퍼티 파일을 코드에서 사용하는 방법은 여러가지가 있다.
• 만일 읽어올 프로퍼티가 많거나 계층형이라면 객체에 바인딩하여 사용하는 것을 고려하자.
• 프로퍼티값을 객체에 바인딩하여 빈으로 등록 후 사용을 위해서는 @ConfigurationProperties(prefix = "test"), @EnableConfigurationProperties, @ConfigurationPropertiesScan({"base.package1", "base.package2"}) 같은 애노테이션을 조합한다.
• 프로퍼티 바인딩시 검증을 위해서는 @Validated와 javax.validation 애노테이션을 사용한다.

SpringApplication이 시작한 시점에 특정 코드를 실행하고자 한다면, ApplicationRunner나 CommandLineRunner를 활용할 수 있다.
두 개의 Runner 인터페이스 중 하나를 선택하여 implements하여 메서드를 오버라이드하고, 빈으로 등록해주면 사전 준비는 완료된다.

ApplicationRunner

run(ApplicationArguments args) 메서드 하나만 오버라이드하면 되며 파라미터인 ApplicationArguments에 바인딩된 어플리케이션 아규먼트들에 접근이 가능하다.
ApplicationArguments는 여러가지 편리한 메서드를 제공하고 있다. 그러므로 아래에서 설명할 CommandLineRunner보다 사용이 권장된다. 아래는 커맨드로 Option, Non-Option Argument를 설정 후 기동 했을 때의 테스트 코드이다.

어플리케이션 기동 커맨드 : java -jar MySpringBootApp.jar alone1 alone2 --key1=value1 --key2=value2

  @Component
  public class SimpleApplicationRunner implements ApplicationRunner {
      @Override
      public void run(ApplicationArguments args) {
          System.out.println("======================================================");
          System.out.println("ApplicationRunner - ApplicationArguments ");
          System.out.println("NonOption Arguments : " + args.getNonOptionArgs());
          System.out.println("Option Arguments Names : " + args.getOptionNames());
          System.out.println("key1의 value : " + args.getOptionValues("key1"));
          System.out.println("key2의 value : " + args.getOptionValues("key2"));
          System.out.println("======================================================");
      }
  }

CommandLineRunner

ApplicationRunner와 기능은 같지만 전달되는 아규먼트가 더 불친절하다. 그리고 Option과 Non-Option 아규먼트의 구분도 없고 아규먼트도 단순 배열로 전달된다.
위와 동일한 커맨드로 기동 했을 때의 코드와 로그이다. 

어플리케이션 기동 커맨드 : java -jar MySpringBootApp.jar alone1 alone2 --key1=value1 --key2=value2

  @Component
  public class SimpleCommandLineRunner implements CommandLineRunner {
      @Override
      public void run(String... args) throws Exception {
          System.out.println("======================================================");
          System.out.println("CommandLineRunner - String... ");
          for(String s : args){
              System.out.println("argument : " + s);
          }
          System.out.println("======================================================");
      }
  }

SpringApplication은 main() 메서드에서 시작되는 스프링 어플리케이션의 초기 설정을 제어할 수 있는 클래스이다.
일반적으로는 main() 메서드 안에서 어플리케이션의 실행을 SpringApplication.run() 메서드에게 위임하거나, SpringApplication 객체를 만들어 run() 메서드를 실행할 수 있다.

public static void main(String[] args) {
    SpringApplication.run(MySpringConfiguration.class, args); // static 메서드로 기동
}

public static void main(String[] args) {
    SpringApplication app = new SpringApplication(App.class); // 객체를 생성하여 기동
    app.run(args);
}

SpringApplication이 초기화 되면서 어플리케이션이 구동될 때 발생하는 이벤트나 에러시 동작하는 FailureAnalyzer 등에 대해 먼저 알아본다. 

FailureAnalyzers

어플리케이션 실행시 오류가 발생한 경우에 동작하며, 에러에 대한 내용과 에러를 고치기 위한 Action을 출력한다.
이미 많은 FailureAnalyzers가 등록되어 있고, 추가도 가능하다.

Application Events and Listeners

스프링에서 제공하는 ContextRefreshedEvent 외에도 스프링부트의 SpringApplication은 추가적인 어플리케이션 이벤트들을 보낸다.
어플리케이션 기동이 시작되면 각 단계에 따라서 ApplicationStartingEvent를 시작으로 이벤트들이 발생하고, 발생된 이벤트들은 이벤트리스너에 전달된다. 각 단계별로 어떤 이벤트가 발생하는지는 아래 스프링부트 공식문서를 참고하자.

https://docs.spring.io/spring-boot/docs/2.2.2.RELEASE/reference/html/spring-boot-features.html#boot-features-application-events-and-listeners

이벤트리스너가 빈으로 등록되어 있고, 리스너의 표적 이벤트가 발생하면 자동으로 처리메서드가 실행된다.
아래 코드와 로그는 빈으로 등록된 ApplicationStartedEvent리스너가 어플리케이션 기동시 출력된 로그이다.
SampleListener 클래스가 @Component 애노테이션으로 빈등록 되었으며, 기동시 ApplicationStartedEvent 이벤트가 발생하면서 자동으로 onApplicationEvent() 메서드가 호출된다.

@Component // 빈으로 등록한다.
public class SampleListener implements ApplicationListener<ApplicationStartedEvent> {
    @Override
    public void onApplicationEvent(ApplicationStartedEvent applicationStartedEvent) {
        System.out.println("ApplicationStartedEvent가 발생!");
    }
}

어플리케이션 기동시 마지막에 콘솔로그가 출력된다. (ApplicationStartedEvent가 기동시 제일 마지막에 발생하기 때문이다.)

하지만 ApplicationStartingEvent의 경우 ApplicationContext가 초기화 되기 전에 발생하는 이벤트기 때문에, 빈 등록으로는 리스너가 동작하지 않는다.(ApplicationContext에 빈이 등록되는데, 이 과정보다 먼저 이벤트가 발생하므로 이벤트 발생시점에는 리스너가 있는지도 모르는 상태이다.) 이런 경우에는 SpringApplication에 addListeners() 메서드로 리스너를 추가하면 된다.
아래 코드는 SpringApplication.run()으로 바로 시작하지 않고, 객체 생성을 통해 설정을 추가했다.

@SpringBootApplication
public class App {
    public static void main(String[] args) {
        SpringApplication app = new SpringApplication(App.class);
        app.addListeners(new SampleListener()); // 리스너를 코드로 추가한다.
        app.run(args);
    }
}

// 이미 SpringApplication에 리스너를 등록했으므로 빈등록이 필요없다.
public class SampleListener implements ApplicationListener<ApplicationStartingEvent> {
    @Override
    public void onApplicationEvent(ApplicationStartingEvent applicationStartingEvent) {
        System.out.println("ApplicationStartingEvent 발생!");
    }
}

어플리케이션 기동시 처음에 콘솔로그가 출력된다. 로그를 복붙하다보니 좀 깨지지만 그건 중요한게 아니다.

WebApplicationType

SpringApplication에서는 ApplicationContext의 타입이 내부적으로 확정된다.
3개의 타입이 존재하는데 다음과 같이 자동설정되며 SpringApplication의 setWebApplicationType() 메서드를 이용하여 코드에서 특정타입으로 오버라이드가 가능하다.

• WebApplicationType.SERVLET : Spring MVC가 존재하면 설정됨
• WebApplicationType.REACTIVE : Spring MVC가 없고, Spring WebFlux가 존재하면 설정됨
• WebApplicationType.NONE : 위의 경우에 해당이 안되면 설정됨. 어플리케이션이 기동 되었다가 바로 종료된다.

@SpringBootApplication
public class App {
    public static void main(String[] args) {
        SpringApplication app = new SpringApplication(App.class);
        // ApplicationType 설정을 오버라이드 한다.
        app.setWebApplicationType(WebApplicationType.SERVLET);
        app.run(args);
    }
}

스프링부트에서 의존성을 추가하고 싶을 때 주로 스프링부트에서 제공하는 starter 라이브러리를 의존성 설정파일에 추가한다.
예를들어 Mybatis 라이브러리를 추가하고자 하면 제공되는 starter 라이브러리를 의존성설정파일(메이븐의 경우 pom.xml)에 아래처럼 추가한다. starter 라이브러리는 단순히 의존성만 추가되는 것이 아니라 자동설정을 포함 하는데, 이것에 대해 자세히 알아본다.

<dependency>
	<groupId>org.mybatis.spring.boot</groupId>
	<artifactId>mybatis-spring-boot-starter</artifactId>
	<version>2.1.1</version>
</dependency>

mybatis starter 라이브러리를 기준으로 포스팅할 예정이며 다른 라이브러리도 비슷하다.

mybatis-spring-boot-starter

스프링부트 프로젝트의 pom.xml에 추가한 mybatis-spring-boot-starter 자체에는 많은 파일이 있지는 않다.
META-INF 폴더에 pom.xml과 pom.properties 파일만 있는 정도이다.
아래는 mybatis-spring-boot-starter의 파일구성과 pom.xml이다. starter의 pom.xml에는 사용될 다른 라이브러리와 autoconfigure(mybatis-spring-boot-autoconfigure) 라이브러리가 포함되어 있는 것을 볼 수 있다.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>org.mybatis.spring.boot</groupId>
    <artifactId>mybatis-spring-boot</artifactId>
    <version>2.1.1</version>
  </parent>
  <artifactId>mybatis-spring-boot-starter</artifactId>
  <name>mybatis-spring-boot-starter</name>
  <properties>
    <module.name>org.mybatis.spring.boot.starter</module.name>
  </properties>
  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter</artifactId>
    </dependency>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-jdbc</artifactId>
    </dependency>
    <dependency>
      <groupId>org.mybatis.spring.boot</groupId>
      <artifactId>mybatis-spring-boot-autoconfigure</artifactId>
    </dependency>
    <dependency>
      <groupId>org.mybatis</groupId>
      <artifactId>mybatis</artifactId>
    </dependency>
    <dependency>
      <groupId>org.mybatis</groupId>
      <artifactId>mybatis-spring</artifactId>
    </dependency>
  </dependencies>
</project>

mybatis-spring-boot-autoconfigure

pom.xml 중간에 추가된 autoconfigure는 자동설정 클래스를 포함하고 있다.(spring.factories 및 XxxAutoConfiguration.class 포함)

스프링부트 프로젝트 기동시 메인 클래스의 @EnableAutoConfiguration 애노테이션이 spring.factories 파일을 읽어들여 자동설정을 진행하는데 자세한 내용은 이전 포스팅을 참고하자.

이전 포스팅 링크 :

2020/12/01 - [Dev/스프링부트] - @SpringBootApplication에 대해서(Springboot 기본구조)

mybatis-spring-boot-autoconfigure의 내용(위 사진)을 보면 MybatisAutoConfiguration 자동설정클래스도 보이고, MybatisProperties 프로퍼티 클래스도 보인다. 이 중 프로퍼티 클래스에 대해 좀 더 살펴보면 보통 어플리케이션에 프로퍼티 설정을 위해 application.yml, application.properties와 같은 파일을 두고 키-값으로 프로퍼티를 작성한다. 이 값들을 스프링부트가 읽어 들여 변수에 세팅하는 클래스가 MybatisProperties 같은 프로퍼티 클래스이다.

좀 더 자세히 보자. MybatisProperties의 소스코드 일부이다. @ConfigurationProperties는 외부 프로퍼티를 사용하는 클래스라는 의미이고 prefix값을 지정할 수 있다. 예를들어 application.properties에서 'mybatis'로 시작하는 프로퍼티를 작성하면 읽어 들여 클래스의 변수에 바인딩된다.
mybatis.configLocation 프로퍼티 작성 -> MybatisProperties 클래스의 configLocation 변수에 바인딩

  @ConfigurationProperties(prefix = MybatisProperties.MYBATIS_PREFIX)
  public class MybatisProperties {
    public static final String MYBATIS_PREFIX = "mybatis";
    private String configLocation; // 프로퍼티 설정파일에서 값을 읽어들여 바인딩된다.
    // 생략
  }

변수가 바인딩된 프로퍼티 클래스를 AutoConfiguration 자동설정 클래스에서 @EnableConfigurationProperties(MybatisProperties.class) 애노테이션을 마킹하여 바인딩된 변수(프로퍼티 설정파일의 값)를 이용하여 자동설정 한다.

  @org.springframework.context.annotation.Configuration
  @ConditionalOnClass({ SqlSessionFactory.class, SqlSessionFactoryBean.class })
  @ConditionalOnSingleCandidate(DataSource.class)
  @EnableConfigurationProperties(MybatisProperties.class)
  @AutoConfigureAfter({ DataSourceAutoConfiguration.class, MybatisLanguageDriverAutoConfiguration.class })
  public class MybatisAutoConfiguration implements InitializingBean {
      private static final Logger logger = LoggerFactory.getLogger(MybatisAutoConfiguration.class);
      private final MybatisProperties properties; // 바인딩된 properties
      // 생략
  }

요약

스프링부트에서 의존성을 추가하고 싶다면 제공되는 stater가 있는지 알아본다.
starter는 단순히 라이브러리를 추가하는 것에 더해서 autoconfigure 라이브러리를 참조한다.
autoconfigure의 spring.factories에 정의된 자동설정 클래스들이 실행되고 스트링부트 프로젝트의 application.properties 같은 프로퍼티 설정파일에서 값을 읽어 들여 자동설정에 사용한다.