다음은 TestRestTemplate 링크 를 번역하면서 공부한 글입니다. 🙌 기존에 RestTemplate을 활용하여 통합테스트를 많이 했을 것이다. 스프링부트에는 굉장히 비슷하게 동작하는 TestRestTemplate이 있다. 두가지 모두 통합테스트에서 유용하며 HTTP API를 다룰 수 있다. TestRestTemplate의 예시를 한번 들여다보자. RestTemplate과 거의 유사한 형테를 지니고 있다. 하지만 TempRestTemplate은 RestTemplate을 확장하지 않으며 몇가지 다른 기능을 제공한다. 🌩 TestRestTemplate은 무엇이 다를까? 1. Auth Credentials을 설정할 수 있는 생성자를 제공한다. TestRestTemplate을 생성할 때 기본 authentication을 설정하여 생성할 수 있다. 그러면 해당 인스턴스를 활용한 모든 요청이 해당 credential이 적용된 채로 수행된다. 2. HttpClientOption을 제공하…

다음 링크를 읽고 정리한 내용입니다 🙌 이전에 작성했던 글이 있습니다. 스프링부트에서 지원하는 여러 테스팅 기법들을 통해서 단위 테스트나 스프링 컨텍스트를 띄우는 통합 테스트를 진행할 수 있다. 사전 준비로는 스프링부트 프로젝트에 의존성을 추가해야한다. 🌩 @SpringBootTest 통합테스트 통합테스트는 어플리케이션의 여러 레이어의 통합 로직을 테스트 하는 것이다. 따라서 mocking을 하지 않는다. 원칙적으로는 통합테스트는 단위테스트와 분리되어 있어야하며 실행 또한 분리해서 실행해야 한다. 다른 profile 환경으로 나누고 통합테스트만을 분리하여 실행해야한다. 이렇게 해야하는 이유 중 하나는 통합 테스트는 어플리케이션 컨텍스트를 띄우는 작업을 필요로 하기 때문에 상대적으로 긴 시간이 소요된다. 또한 실제 데이터베이스의 실행을 필요로 하기도 한다. 은 컨테이너 전체를 띄우는데 유용하다. 이 어노테이션은 테스트에 사용될 ApplicationContext를 생성하여 테스트…

Intro 프로젝트를 진행하다 보면 상황에 따라 각기 다른 운영환경을 설정해야할때가 있다. 그때마다 properties 설정 파일에 가서 설정되어있는 운영 환경을 바꾸고 돌리기는 어렵다. 이때 각기 다른 를 적용해서 상황에 따라 적합한 설정을 따르도록 할 수 있다. yml 파일로 설정 나누기 - 간단하게 또는 를 통해서 profile 설정을 나눌 수 있다. 각각 원하는 환경에 대한 설정정보를 , 에 기재한 후 또는 로 지정한다. 여러 profile 환경으로 나눠져 있을 경우 어떤 profile을 기본적으로 실행할 것인지 에 지정해 주어야 한다. 나누어진 profile을 적용하기 위해서는 로 적용하고자하는 프로필을 지정하여 실행하거나 어노테이션을 활용할 수 있다. 사용 예시 본인은 프로젝트 진행 시 다음과 같이 local, prod, test로 환경을 나누었다. application-local.yml application-prod.yml application-test.yml …

Intro 스프링부트 프로젝트를 진행하다보면 웹 mvc에 대한 테스트를 진행해야할 때가 있다. 때로는 각 layer에 대한 슬라이스 테스트를 작성하거나, 일부분에 대한 통합 테스트만을 진행할 때 Mock 테스트를 해야할 때도 있다. 테스트 관련 annotation에 대해서 정리하고 각 annotation의 차이 및 언제 무엇을 사용하면 좋을지 정리해본다. 어노테이션은 을 찾아 해당 configuration에 맞추어 실제 Spring web context를 실행햔다. Spring context의 설정으로 그대로 적용해서 테스트를 진행해야 할 경우에 해당 어노테이션을 붙여서 테스트를 하는 것이 좋다. 하지만 전체 컨텍스트를 로드하는 만큼 굉장히 오랜 시간이 걸린다. 실제로 어노테이션이 붙은 테스트를 돌려본다면 다음과 같은 스프링 컨텍스트르 로딩하는 긴 로그가 찍히는 것을 확인할 수 있다. 위 어노테이션은 다음과 같이 를 주입받아서 톰캣 서버를 띄우지 않은 상태로 API 요청 …

를 통해서 어플리케이션 전역적으로 exception을 핸들링 할 수 있다. 다르게 표현하면 메서드에서 던져지는 exceptions들의 interceptor라고 할 수 있다. (shared across multiple @Controller classes) 주로 에서 전역적으로 처리하고 싶은 어노테이션은 , , 등이 있다. 클래스가 어노테이션에서 전역적인 exception handling 을 구현할 수 있도록 하는 base class이다. 해당 클래스에서 Spring MVC 내부에서 발생한 예외들을 처리할 수 있는 메서드들을 제공한다. (는 를 반환하는 반면 는 를 반환한다) 여러 @ControllerAdvice 간의 우선순위 @ControllerAdvice 클래스들은 Bean으로 등록이 되도록 하는데, 해당 빈들은 인터페이스를 구현하여 orderable 한 속성을 부여하거나, / 를 사용해서 우선순위를 부여할 수 있다. (여기서 semantic이 / 에 우선순위를 가진다…

Spring Boot Spring boot 자체에서 핸들링 되지 않은 error 에 대한 대비책을 마련해 두었다. 먼저, Spring boot 자체에서 에 대한 매핑을 찾아서 해당 URL에 대해서 동일한 이름을 가진 뷰를 매핑 한다. 해당 뷰는 을 반환한다. (해당 뷰는 Thymeleaf template인데, 만일 JSP를 사용한다면 를 반환하도록 에서 변경할 수 있다) 실질적인 매핑은 ViewResolver에서 담당한다. 만일 에 대해 그 어떠한 view-resolver도 매핑이 되어 있지 않다면 spring boot는 내부적으로 가지고 있는 대체 에러 페이지인 “Whitelabel Error Page”를 가지고 있다. 이때 만일 RESTful request에 대한 응답이라면 Spring boot는 자체적인 JSON 형태로 “Whitelabel Error Page”의 응답을 받은 error 정보를 반환한다. Spring boot는 컨테이너에 대한 디폴트 error-page…

@RequestBody request body를 method argument로 바꿀 때 를 사용한다. 는 두가지를 담당한다. 첫번째는 Http request message를 객체로 변환하는 것, 두번째는 객체를 Http response body로 변환하는 작업이다. 동작원리 에 의해서 호출되는 handler의 method parameters은 스프링의 에 의해 생성이 되고, handler의 return value는 에 의해서 처리된다. 와 를 다루는 구현체는 이다. DispatcherServlet의 handle에서부터 Argument resolve 하는 과정 → → → → → → → (Interface) → (Imp) 내부에서 HttpMessageConverter를 사용해서 변환시키는 과정 → (extends AbstractMessageConverterMethodArgumentResolver) → (Imp HandlerMethodArgumentResolver) …

@Valid - 스프링 부트에서 어노테이션으로 validation을 할 수 있도록 기능을 추가해주는 것. 즉, controller에서 인자를 받을 때 유효성 검사를 할 수 있도록 해주는 것이다. DTO의 필드나, 도메인 객체의 필드 위에 유효성 검사를 하고 싶은 어노테이션을 추가하고, controller의 인자 앞에 @Valid 를 추가해서 붙여준다. java.validation 어노테이션 사용 예시

트랜잭션을 사용하는 이유 트랜잭션을 사용하면 각각의 단위로 나누어져있는 작업의 단위를 하나로 합칠 수 있다. 즉, 일련의 연산들을 하나의 독립된 작업 단위로 보고 하나로 취급하기 위해서 사용하는 것이다. 언제 일련의 연산들을 하나로 봐야 할 때가 생길까? 예를 들어서 돈을 송금하는 시스템이 있다고 가정해보자. 계좌A에서 계좌B로 돈을 송금해야 할 때, 계좌A에 충분한 잔액이 있는 것을 확인하고 돈을 송금하기 위해서 돈을 차감했다. 그리고 계좌B에 입금을 하려고 하는 순간 예외가 발생하면서 입금을 하지 못했다. 그런데 계좌A에서는 여전히 돈이 차감된 상태이다. 중간에 송금하려고 했던 돈이 사라지게 된 것이다. 이때, 위의 과정을 로 관리를 하게 된다면 위의 여러 작업들을 하나의 단위로 보고 중간에 예외가 발생한다면 위에서 실행중이던 작업을 한꺼번에 롤백해준다. 트랜잭션 기본 방법 2개 이상의 쿼리를 하나의 커넥션으로 묶어 DB에 전송하고, 에러가 발생할 경우 자동으로 모든 과정…

제일 핵심이 되는 차이점은 HTTPResponse Body의 생성 방식이다. @Controller 본래 Spring MVC 컨트롤러의 주 역할은 View를 반환하는 것이다. 아래 사진을 보면, 클라이언트가 URL을 통해서 Dispatcher Servlet 에 요청을 보내면 적절한 Handler를 매핍하고 컨트롤러에서 해당 View를 를 통해서 반환한다. 하지만 컨트롤러는 항상 View를 반환하는 것이 아니라 data도 반환해야한다. 이때는 @ResponseBody 어노테이션을 통해서 Json 형태로 클라이언트에 데이터를 반환할 수 있도록 해야 한다. 이때는 View를 반환할 때 사용하는 ViewResolver를 반환하는 것이 아니라 HttpMessageConverter 을 사용해서 데이터를 반환한다. 따라서 Data를 반환하는 응답에 대해서는 를 붙여주어야하는데 매번 그러기가 번거로우니 Controller에 가 자동으로 붙어있는 가 등장하게 된 것이다. @Controller

이번에 스프링 체스 자바 웹 어플리케이션을 사용하여 구현하면서 처음에는 모두 으로 데이터를 가져왔었다. 하지만 인자가 너무 많아지는 경우 메서드에 파라미터가 많아지면서 가독성이 안 좋아졌다. 또한 DTO에 해당 데이터를 담아서 서비스 레이어에 전달해야하거나 할 때 일일이 데이터를 DTO에 담아서 가공해야 하는 작업을 해야하기도 했다. 코드를 구현할 때 손가락이 아프다면 수정할 부분을 찾으라고 했었는데 확실히 으로 받는 것은 손가락이 아팠다. 아니나 다를까 리뷰어가 @ModelAttribute를 사용하는 걸 추천했다. 마침 레벨1 제이슨 톡방에서도 @ModelAttribute 에 대한 논의가 활발하길래 공부도 하고 코드에 적용을 하며 배운 것을 기록해본다. @ModelAttribute vs. @RequestBody 간단하게 말하면 다음과 같다. 같은 경우는 parameter 값으로 DTO에 바인딩한다. 따라서 해당 DTO 객체에 메소드가 반드시 있어야 한다. 따라서 타입에 대…