해당 게시글은 최범균님의 테스트 주도 개발 시작하기와 박우빈님의 실용적인 테스트 강의 내용 중 테스트 코드 작성 주의사항을 정리한 내용입니다. 되게 테스트 상황에 맞는 예시를 생각해내기 어려워서 강의 내용, 개인 테스트 코드, 블로그에서 코드를 가져왔음을 알립니다. 1. 테스트 코드에서 순서는 보장되어 있지 않을 수 있다. 테스트 코드를 짜다보면 성공할 때도 있고 실패할 때도 있는 테스트가 있다. 랜덤 혹은 시간이라는 변수와 관련이 없다면 테스트 코드 혹은 동작하는 코드의 순서 때문에 발생하는 문제일 가능성이 크다. 테스트 코드의 순서 문제로 발생하는 것은 보통 DB와 연관이 있다. 데이터를 제 때 지워주지 않아서 예상했던 조회와 다르다던가하는 문제가 발생한다. 그런 문제가 발생할 때에는 보통 @Afte..

해당 게시글은 최범균님의 테스트 주도 개발 시작하기와 박우빈님의 실용적인 테스트 강의 내용 중 Mock 사용법을 정리한 내용입니다. 되게 테스트 상황에 맞는 예시를 생각해내기 어려워서 강의 내용, 개인 테스트 코드, 블로그에서 코드를 가져왔음을 알립니다. 1. Mock으로 기본 가짜 응답 만들기   DB와 연결된 부분이며 이미 기능적으로 검증이 완료된 부분은 Mock으로 가짜 객체를 만드는 것을 고려해보는 것이 좋다. 왜냐하면, 굉장히 시간이 오래 걸리며 데이터를 주입하고 관리하는 부분이 오히려 가독성을 해치고 관리하기 어렵게 만들기도 하기 때문이다.  과거 컨트롤러 테스트 글을 작성했을 때 요청에 따른 데이터 조회 부분을 Mock으로 대체해서 설정한 값에 따른 응답을 설정해놓은 적이 있었다.// giv..

1. 컨트롤러, 검증, ExceptionHandler 코드 확인 우선 작성한 컨트롤러 코드부터 확인해보자. 딱 1개의 API만이 있다. 가게를 찾기 위한 요청 정보를 URL의 파라미터로 받아 서비스 계층에서 사용할 수 있는 요청으로 바뀐 뒤, 가게를 찾는다. 이 때, 가게를 찾지 못하면 예외를 던지고 찾으면 상태코드 200과 함께 응답을 던진다. @RestController @RequiredArgsConstructor public class ShopController { private final ShopService shopService; @GetMapping("/api/findShop") public ResponseEntity findShop(@Valid @ModelAttribute ShopSearch..

[ 들어가기 전에 ] 앞의 1편부터 3편까지의 글을 작성하면서 컨트롤러에서 공통적인 로직을 처리하기 위해서 필터로 로깅이나 인증/인가를, 검증을 따로 지원하는 javax.validation을 사용해서 컨트롤러와 분리하는 방법에 관해서 알아보았다. 이제는 컨트롤러 단에서 예외가 발생했을 때 어떻게 처리해야 하는가에 관해서 이야기를 해보고자 한다. 우선 이걸 알아보기 전에 컨트롤러에서 예외를 일으켜보고 응답을 보면서 시작해보자. @GetMapping("/controller/exception") public void exception(){ throw new IllegalArgumentException(); } 위의 코드를 포스트맨을 통해서 작동시켜보면 아래와 같이 에러가 뜰 것이다. 분명히 아무런 작업을 해주..

[ HTTP 요청과 검증 처리 ] HTTP로 요청이 날아오면 컨트롤러에서는 보통 쿼리 파라미터, 바디, 헤더, 쿠키의 4가지 값들을 처리한다. 이게 가능한 이유는 Dispatcher Servlet 때문이며 그 안에는 HTTP 메시지 컨버터와 요청 매핑 핸들러 어댑터로 애노테이션에 따라 적절한 컨버터와 핸들러를 매칭하기 때문이다. 그래서 컨트롤러에서는 딱히 파라미터의 순서, 파라미터 종류에 관해서 웬만한 게 다 있다. 예를 들어, 가게의 이름과 가격을 통해 검색을 하는 상황이 있다고 해보자. 이 때, 쿼리 파라미터 값이 들어오지 않거나, 쿼리 파라미터 값이 int 타입인데 값이 범위를 지나거나 하는 경우, 예외를 처리해주어야 한다. 이 예외처리는 어디에서 해줘야할까? 아마 검증에 관해서 모른다면 다음처럼 ..

[ 필터 ] 필터는 스프링의 프론트 컨트롤러인 Dispatcher Servlet에 요청이 도달하기 전 URL 패턴에 맞는 모든 요청에 대해 부가작업을 처리하는 기능을 제공한다. 해당 코드를 작성한 사람이 남긴 목적에 의하면 총 9가지 용도로 세분화해서 사용할 수 있다고 적혀있다. 하지만 요약해보면 데이터 압축 및 변환, 로그인 인증 및 인가, 로그 이렇게 3개로 요약이 가능할 것 같다. 아래의 코드는 Filter 인터페이스에 코드로 메서드는 총 3가지가 있다. 그런데 init이나 destory를 써본 적이 없다. 생성자 주입 방식으로 필요한 객체를 주입 받는 방식을 보통 사용했었기 때문이다. 그래서 제일 중요한 메서드는 doFilter인데 외부의 request 요청 값을 받아 여러 처리를 하여 쓰레드 로..