# mockMvc

more

문제 게시글 작성 테스트 게시글 작성 테스트 중에 발생한 문제가 있었다. 결과값으로 문자열이 한글로 나와야 하는데 제대로 인코딩이 되지 않았는지 이상한 문자가 나오고 fail이 되었다. 시도 게시글 작성 테스트 처음으로 시도한 방법은 다음과 같다. 설정 > 에디터 > 파일 인코딩 => 인코딩 부분을 전부 UTF-8로 변경 => 프로퍼티 파일 부분에서 명확한 Native에서 ASCll로의 변환 체크 idea64.exe.vmoptions 파일에 -Dfile.encoding=UTF-8 추가 도움말 > 사용자 지정 VM 옵션 편집에 -Dfile.encoding=UTF-8 추가 하지만 여전히 제대로 동작하지 않았고 또 다른 방법을 찾아보아야 했다. 시도한 다른 방법은 BeforeAll을 사용해서 미리 인코딩을 해주는 것이다. 하지만 이 방법을 사

hjin10833

Mock Mock이란 모조품이라는 뜻으로, Mock 객체란 실제의 모듈을 흉내내는 가짜 모듈을 작성하여 테스트의 효용성을 높이는 데 사용하는 객체. Mockito mock을 쉽게 만들고 mock의 행동을 정하는 stubbing이나 정상적으로 작동하는지에 대한 verify 등 다양한 기능을 제공해주는 프레임워크. Mock 객체를 직접 구현하지 않아도 됨. Mockito 설정 의존성 설정 테스트 클래스 위에 @ExtendWith(MockitoExtension.class) 붙여야 함. MockMVC 브라우저에서 요청과 응답을 의마하는 객체로서 Controller 테스트를 용이하게 해주는 라이브러리. MockMVC 메서드 perform() : 요청을 전송하는 역할. 결과로 ResultActions 객체를 받으며, ResultAction

gale4739

이전 포스팅 링크 : https://velog.io/@gale4739/Spring-Boot-%EC%98%A4%EB%A5%98-%EA%B0%9C%EC%84%A0-1.-%EC%9D%B8%EC%A6%9D-%EB%A1%9C%EC%A7%81-%EC%88%98%EC%A0%95 안녕하세요 이번 시간은 지난 포스팅에서 MockMvc 환경에서 UsernamePasswordAuthenticationFilter를 사용하여 검증하는 방법에 대해 포스팅하도록 하겠습니다. 우선 검증 방법은 굉장히 단순합니다. 바로 MockMvc 인스턴스 생성 시 빌더 내부에 .apply(SecurityMockMvcConfigurers.springSecurity()) 를 추가해주면 됩니다. 하지만 여기서 추가 순서가 매우 중요합니다. 위의 코드처럼 커스텀 필터보다 앞에 추가할 경우 커스텀 필터가 적용되기 전 먼저 Spring Security이 적용됩니다. 반면 커스텀 필터보다 뒤에 추가할 경우

shwncho

문제 원인 Spring Boot 3.x 버전을 사용하면서 Spring security도 6.x를 사용하게 됐다. 그런데 Spring Boot 2.x 버전과 Spring security 5.x 버전을 사용하면서 나타나지 않았던 문제가 생겼다. 보통 csrf랑 연관되서 403 에러가 나지만, Jwt를 사용하기 때문에 SecurityConfig에서 이미 disable을 해준 상황이다. 그래서 Spring security 5.x -> Spring security 6.x 의 변화된 부분을 공식문서를 통해 확인한 결과 더 이상 모든

morion002

Graph 최소 신장 트리 그래프의 정점과 간선 중 일부를 선택해서 구성하는 트리를 신장 트리라고 한다. 가중치 그래프일 때, 가장 적은 비용으로 모든 정점들을 연결하는 것이다. 최소 신장 트리는 순환하는 사이클 구조를 절대 가져서는 안 된다. Kruskal 노드의 개수가 n개일 때 간선을 가중치 기준으로 오름차순 정렬 가중치를 낮은 간선부터 선택 이때 간선으로 인해 사이클이 생기면 다음 간선 선택 선택한 간선이 n-1 개가 될 때까지 반복 코드로 구현하면 다음과 같다. Prim 하나의 정점에서 시작해서 정점을 하나씩 추가하는 알고리즘이다. 임의의 시작 정점을 선택 현재 선택된 정점들을 기준으로 인접한 정점 중 가

gale4739

안녕하세요 오늘은 MockMvc 객체에 필터를 적용하는 방법에 대해 포스팅해보도록 하겠습니다. 저번 포스팅에서 커스텀 필터를 만들어 적용하는 과정에서 테스트 시 필터가 제대로 적용되지 않는 문제가 있었습니다. 문제 해결은 단순했습니다. 바로 생성한 MockMvc 클래스에 필터를 추가하는 것입니다. MockMvc 클래스는 실제 서블릿 컨테이너를 사용하지 않고 가상의 서블릿 컨테이너를 이용하여 테스트용으로 시뮬레이션하는 역할을 담당합니다. 따라서 실제 서비스에 필터가 적용되었더라도 MockMvc에서는 가상의 환경에서 진행하기 때문에 필터가 적용되어 있지 않은 상태입니다. 따라서 아래의 코드처럼 MockMvc 객체를 생성 시 .addFilter를 통해 추가하고자 하는 커스텀 필터를 추가해줍니다.

gale4739

안녕하세요 오늘은 Spring Boot에서 JWT를 커스텀하여 원하는 정보를 내부에 추가하는 작업에 대해 포스팅하려고 합니다. 우선 현재 인증/인가 프로세스에 대해 살펴보면 @Configuration 클래스 내부에 SecurityFilterChain 클래스를 생성 및 수동으로 Bean을 주입한다. (@Bean 이용) 요청이 디스패쳐 서블릿(DispatcherServlet)에 들어오기 전에 인증/인가 작업을 진행해야 하기 때문에 통신 시 필터를 추가하여 보안 관련 설정을 추가합니다. 여기서 주의할 점은 @Configuration 어노테이션을 추가한 이후 @Bean을 사용해야 한다는 점입니다. 없어도 가능하지만 싱글톤 패턴을 보장받을 수 없어 불필요한 여러 빈이 생성될 수 있습니다. 하지만 @Configuration 어노테이션은 프록시 패턴이 적용되어 기존과 동일한 객체를 반환합니다. 커스텀한 필터에서 헤더에 존재하는 토큰을 가져온 후 유효성 검사 과정으로 토큰을

iseon_u

MockMvc, Rest Assured 차이 MockMvc 주로 컨트롤러 단위 테스트에 사용 빠른 테스트 @WebMvcTest를 사용 가짜 객체를 만들어서 요청 처리 Rest Assured 주로 End-to-End Test 전 구간 테스트에 사용 비용 높은 느린 테스트 항상 @SpringBootTest를 사용 실제 요청으로 처리 | | MockMvc | Rest Assured | | --- | --- | --- | | 사용 범위 | 컨트롤러 단위 테스트 | 전 구간 테스트 | | 사용 객체 | 가짜 객체 요청 | 실제 요청 | | 속도 | 상대적으로 빠름 | 오래 걸림 | | 가독성 | 낮음 | BDD 스타일, 높음 | Dependency MockMvc Spring Framework Test 클래스 중 하나 Spring test 의존성이 추가되어 있는 경우 사용 가능

gale4739

안녕하세요 오늘은 Spring Boot Configuration 설정 방법에 대해 포스팅해보겠습니다. 위의 코드를 보시면 빨간 줄로 " 자동 주입을 할 수 없습니다. 해당 타입의 bean을 찾을 수 없습니다. " 과 같은 문구가 나옵니다. 하지만 실제 프로그램을 실행시켰을 때 이상 없이 잘 동작해서 넘어갔는데 왜 자동 주입이 되지 않았는지 궁금해서 원인을 찾아

arin

MockMvc 란 ? MockMvc는 웹 애플리케이션을 애플리케이션 서버에 배포하지 않고도 스프링 MVC의 동작을 재현할 수 있는 클래스이다. ||@WebMvcTest|@SpringBootTest| |---|---|---| |특징|컨트롤러의 역할만을 테스트|모든 스프링 빈을 등록| |장점|1. 특정 클래스만 지정하여 보다 가볍고 빠른 테스트 가능 2. 통합테스트 진행하기 어려운 테스트를 개별적으로 진행 가능|애플리케이션의 설정, Bean을 모두 로드하기 때문에 운영환경과 가장 유사한 테스트 가능| |단점|Mock을 기반으로 테스트하기 때문에, 실제 환경에서 예상 밖의 동작오류 가능성 발생|경우 모든 빈을 로드하기 때문에 구동 시간이 오래 걸리고, 테스트 단위가 크기 때문에 디버깅이 어려울 수도 있음| @WebMvcTest : 경우 특정 클래스만 지정하여 보다 가볍고 빠른 테스트 가능 @SpringBootTest : 모든 빈을 로드하기 때문에 구동 시간이 오래 걸

devmizz

❗️상황 TDD를 공부하며, 진행하던 프로젝트에서 연습을 진행하고 있었다. 컨트롤러에서 테스트 진행을 위해 @WebMvcTest 어노테이션을 이용하여 진행하는데 문제가 발생했다. Response Body가 비어있다? MockMvc를 이용한 테스트를 진행하는데, 응답은 200으로 잘 오면서 MockHttpServletResponse의 Body가 비어있는 이상한 상황을 겪게 되었다. 아래 코드처럼, 응답으로 나오는 JSON에 대한 검증을 진행하고자 했다. 하지만 Response Body가 비어있어서 'No value at JSON path' 에러와 함께 테스트가 계속 실패했다. Body가 비어있기 때문에 비교할 JSON이 없으므로 해당 에러가 발생한다. 물론 여기서 Status에 대한 검증만을 진

supark4170

View를 리턴하는 단순한 컨트롤러 메서드를 테스트하려 합니다. 제가 아는 스프링 테스트 방법은 TestRestTemplate을 사용하는 것과 MockMvc를 사용하는 것 두가지가 있는데요. 전체 프레임워크를 사용하지 않고 엔드포인트에 바로 Http Request를 날려서 테스트를 진행하는 TestRestTemplate를 사용하지 않고, MockMvc를 사용하기로 했습니다. MockMvc는 Mvc의 컨트롤러를 테스트하는데 특화돼있습니다. Http requset를 모방하여 전체 스프링 context안에서 Controller를 테스트할 수 있습니다. 따라서 Controller를 실제 어플리케이션 환경처럼 model과 viewResolver등 다른 컴포넌트들과의 상호작용 속에서 테스트 할 수 있습니다. 테스트 코드입니다. @Test애노테이션을 Junit5를 사용하고 있기 때문에 @ExtendWith(SpringExtension.class)를

cornchiplick

목차 Test 1. Test 1) @WebMvcTest Application Context를 완전히 실행하지 않고 Web Layer를 테스트하고 싶을 때 고려한다. @SpringBootTest가 모든 빈을 구동하기 때문에 구동시간이 오래 걸리고, 디버깅이 어려울 수 있다. Controller 레이어만 테스트하고 싶을 때 유용하다. 의존객체가 필요하다면 @MockBean으로 주입받는다. @WebMvcTest(Controller.class)로 사용한다. 2) MockMvc 실제 객체와 비슷하지만 테스트에 필요한 기능만 가지는 가짜객체를 만든다. 애플리케이션을 배포하지 않고도, 서버의 MVC동작을 테스트할 수 있는 라이브러리다. 주로 컨트롤러 레이어 단위테스트에 많이 사용된다. 컨트롤러의 메서드를 직접 호출하지 않고 MockMvc를 이용해서 가상으로 호출한다. 3) given, when, then

y005

MockMvc는 Spring MVC의 컨트롤러에 대한 통합 테스트를 지원하는 테스트 프레임워크이다. MockMvcBuilder MockMvc 객체를 생성할 때 MockMvcBulider의 standaloneSetup를 사용하게 되면 개별 컨트롤러에 대한 단위 테스트가 가능하고 webAppContextSetup를 사용하게 되면 실제 웹어플리케이션 프로젝트 환경에서 컨트롤러에 대한 통합 테스트가 가능하다. RequestBuilder mockMvc를 통한 컨트롤러 테스트는 perform 메소드에 테스트하고 싶은 컨트롤러를 호출하기 위해 설정된 RequestBuilder 객체를 넘겨 실행한 결과로 반환된 ResultActions에 대한 검증을 통해 이뤄진다. RequestBuilder는 HTTP request의 method, pathvariable, query param, body 설정을 지원한다. MockMvc 환경 커스터마이징 mockMvcBuilder

selffy

mockMvc란? Mock의 사전적 의미는 '테스트를 위해 만든 모형'을 의미한다. mocking : 테스트를 위해 실제 객체와 비슷한 모의 객체를 만드는 것 mock-up : 모킹한 객체를 메모리에서 얻어 내는 과정 mockMvc란 실제 객체와 비슷하지만 테스트에 필요한 기능만 가지는 가짜 객체를 만들어서 애플리케이션 서버에 배포하지 않고도 스프링 MVC 동작을 재현할 수 있는 클래스를 의미한다. mocMvc 를 이용해서 Controller를 테스트 할 수 있다. 웹 환경에서 컨트롤러를 테스트 하려면 반드시 서블릿 컨테이너가 구동되고 DIspatcherServlet객체가 메모리에 올라가야 한다. 서블릿 컨테이너를 모킹하면 실제 서블릿 컨테이너가 아닌 테스트용 모형 컨테이너를 사용하여 간단하게 컨트롤러를 테스트 할 수 있다. 서블릿 컨테이너를 모킹할 떄 두 가지 어노테이션을 사용할 수 있다. -* @webMvcTest* : @Controller, @Rest

preace11

과제를 하다가 처음으로 테스트 코드를 작성했다... 쉽지 않았다. 생각은 쉽게 했지만, 처음하면 많은 것에 부딪친다. 하지만, 이 역시 이겨내리라. The Top of Iceberg! 💡 개요 테스트 코드를 처음으로 작성해봤는데, 처음에는 그럭저럭 넘어갈만했다. 하지만, @AuthenticationPrincipal을 어떻게 처리해줘야할지... 막막했고 구글링을 했다. 역시 결과가 중요하다. 결과부터 소개한다. 을 이용하면 된다. 테스트 코드의 전문은 아래와 같다. 💡 SecurityMockMvcRequestPostProcessors.user( ) 아래 사진을 보면 SecurityMockMvcRequestPostProcessors 클래스 내부의 user 메서드는 String과 UserDetails를 파라미터로 받는다. 그리고 Authentication.getPrincipal

hjkwon0814

1. JUnit 라이브러리 추가 Spring Framework에서 JUnit을 이용하기 위해서는 Maven Dependency 추가를 해야한다. pom.xml에 dependency를 추가한다. 2개의 dependency를 추가해주면 된다. HomeControllerTest 를 src/test/java 폴더 아래 생성한다. Test를 생성하면 이렇게 나온다. 그 다음으로 해야 할 일은 1. WebApplicationContext를 불러올 수 있게 해주는 Annotation인 @WebAppConfiguration을 추가해야한다. 2. Servlet.Xml파일과 ApplicationC

ssi02121

2장 테스트에서 만난 에러들 > 아래 테스트를 진행하려는데 이런 에러들이 났다.. 1-1) 첫번째 에러 Unable to find a @SpringBootConfiguration, you need to use @ContextConfiguration or @SpringBootTest(classes=...) with your test 1-2) 해결법 이 에러는 디렉토리가 구조가 맞지않아 생기는 에러이다. > 1. 테스트 하려는 컨트롤러와 같은 패키지에 테스트 클래스를 위치하면 해결된다. 그런데 나는 같은 위치였어도 계속해서 같은 에러가 났다. 또 다른 해결법은 에러 로그가 하라는대로 하면된다. >2. @SpringBootTest(classes=...) 로 컨트롤러 클래스 이름을 명시해주면 된다. [예시] @SpringBootTest(classes = HelloController

monkeydugi

서론 팀원들과 Rest Docs와 Swagger 중 무엇을 고민할지 상의했다. 결과적으로는 나의 생각과는 다르게 Rest Docs를 선택했다. Swagger도 튜토리얼 정도만 해봤기 때문에 둘의 장단점을 명확하게 공감하지는 못한다. 그래서 이번에는 팀원들의 의견을 따라 Rest Docs를 사용하며, 장단점을 느껴보자. Spring Rest Docs VS Swagger 내가 Swagger를 원했던 이유 Rest Docs는 문서를 만들기 위한 테스트 코드를 작성해야 한다. 이 부분이 불편하다고 느꼈다. 차라리 컨트롤러에 의존되고 조금 코드가 지저분해지는 것이 좋지 않을까? 라는 생각이었다. Rest Docs는 테스트를 강제화 해서 문서를 만든다는 것이다. 여기서

yshjft

webEnvironment MOCK mock servlet environment으로 내장 톰캣 구동 ❌ RANDOMPORT, DEFINEDPORT 내장 톰캣 사용 NONE 서블릿 환경 제공 안함 @SpringBootTest @SpringBootTest의 WebEnvironment의 기본 값은 Mock이다. Mocking된 Dispatcher servlet에 요청을 보낼 수 있으나 interaction을 위해서는 MockMVC가 필요하다. MockMVC MockMVC를 사용하기 위해서는 @AutoConfigureMockMVC가 있어야 한다. MockMvc는 서블릿 컨테이너의 구동 없이, 시뮬레이션된 MVC 환경에 모의 HTTP 서블릿 요청을 전송하는 기능을 제공하는 클래스다. 내장 톰캣을 사용 restTemplate, testRestTemplate, testWebClient(webTestClient)를 사용해야한다. 정리