티스토리 뷰
문제상황
컨트롤러 테스트를 작성하던 중 Mock 객체를 사용해 서비스 로직 반환 값을 지정했는데도 불구하고 null 값이 반환되는 상황이 발생했다.
@Test
@DisplayName("가게를 정상적으로 생성한다.")
void createSuccess() throws Exception {
StoreRequest storeRequest = createRequest();
StoreResponse storeResponse = createResponse();
when(storeService.save(storeRequest)).thenReturn(storeResponse);
ResultActions resultActions = mockMvc.perform(post("/api/v1/stores")
.with(csrf())
.content(objectMapper.writeValueAsString(storeRequest))
.contentType(MediaType.APPLICATION_JSON)
.characterEncoding(StandardCharsets.UTF_8));
resultActions.andExpect(status().isCreated())
.andExpect(jsonPath("$.id").value(storeResponse.getId()))
.andExpect(jsonPath("$.storeName").value(storeResponse.getStoreName()));
}
storeService의 save 함수가 호출되면 직접 만들어준 storeResponse 값이 반환하도록 모킹 하였다.
발생한 예외는 다음과 같다.
Request processing failed: java.lang.NullPointerException: Cannot invoke "org.dinosaur.foodbowl.domain.store.dto.StoreResponse.getId()" because "storeResponse" is null
storeResponse가 null로 반환된다고 하는데, 모킹을 정확히 했음에도 null이 반환되는 것이 도저히 이해가 가지 않았다.
@PostMapping
public ResponseEntity<StoreResponse> create(@RequestBody @Valid StoreRequest storeRequest) {
StoreResponse storeResponse = storeService.save(storeRequest);
return ResponseEntity.created(URI.create(DEFAULT_PATH + storeResponse.getId())).body(storeResponse);
}
테스트하려고 하는 컨트롤러 메서드는 create 메서드이다. 이전에 진행한 프로젝트에서도 한 번도 이런 에러가 발생한 적이 없었다. 그때 작성했던 테스트 코드, 컨트롤러의 메서드들과 어떤 차이가 있는지 살펴보니, 이전에 진행했던 프로젝트들에서는 모킹한 값을 꺼내서 사용하지 않았었다. 즉, 현재 create 메서드에서 storeResponse.getId()로 값을 꺼내고 있고, 이 부분에서 null 참조가 발생한 것이다.
그렇다면 왜 null 값이 반환되었을까?
이유
우선 디버깅을 먼저 시도했다.
테스트 메서드에서 모킹을 시도한 후 storeRequest와 storeResponse의 주소 값은 각각 8063, 8064이다.
반면에 컨트롤러에서 요청으로 들어온 storeRequest의 주소 값은 8661이다. 내부 값은 모킹할 당시 값과 같은 것도 확인할 수 있다.
즉, 현재 내부 값은 모두 같고, 주소는 다른 객체가 @RequestBody를 거쳐 StoreRequest 객체로 할당된다는 것이다.
결과적으로 @RequestBody로 받아오는 StoreRequest와 관련해서 원인을 찾을 수 있었다. @RequestBody는 ObjectMapper의 readValue() 메서드를 통해 body의 내용을 읽어 json key값들을 해당 타입의 필드에 바인딩을 시켜준다. 그러므로 컨트롤러에서 사용하는 StoreRequest는 Mock에서 정의한 StoreRequest와 값은 같지만 다른 객체인 것이다.
when(storeService.save(storeRequest)).thenReturn(storeResponse);
이 모킹의 뜻은 결과적으로 8063번 주소를 가진 StoreRequest 객체가 save 함수로 전달될 때 storeResponse를 반환한다는 뜻이다.
해결 방법
그렇다면 해결할 수 있는 방법은 무엇이 있을까?
Mocking을 판단하는 과정에서 객체를 비교하므로, 해당 객체(storeRequest)의 equals & hashcode를 구현해 준다면 올바르게 작동한다.
또는 when(storeService.save(..)) 인자로 any()를 넣어줄 수 있다. any()는 save의 인자로 어떤 값이 오더라도 원하는 응답을 내려준다는 것이다. 좀 더 구체적으로 보면 any(A.class)로 설명하면 A라는 클래스가 인자로 오면 ~ 이라는 의미이다.
Request 객체나 DTO는 필드가 적어도 5개 이상 있는 경우가 많으므로 equals, hashcode를 구현해 주기보다는 any()로 선언하는 편이 나은 것 같다. 또한 any()에 구체적인 클래스 타입을 설정해주는 것이 더 꼼꼼하게 테스트할 수 있다.
만약 void 타입이나 primitive 타입을 인자로 하는 메서드를 mocking 하거나, GET을 mocking 하는 굳이 신경 쓰지 않아도 된다.
@Test
@DisplayName("가게를 정상적으로 생성한다.")
void createSuccess() throws Exception {
StoreRequest storeRequest = createRequest();
StoreResponse storeResponse = createResponse();
when(storeService.save(any())).thenReturn(storeResponse);
ResultActions resultActions = mockMvc.perform(post("/api/v1/stores")
.with(csrf())
.content(objectMapper.writeValueAsString(storeRequest))
.contentType(MediaType.APPLICATION_JSON)
.characterEncoding(StandardCharsets.UTF_8));
resultActions.andExpect(status().isCreated())
.andExpect(jsonPath("$.id").value(storeResponse.getId()))
.andExpect(jsonPath("$.storeName").value(storeResponse.getStoreName()));
}
요약하면
Mocking 과정의 when 절에서 판단하는 부분은 객체를 비교한다. 객체를 비교하므로 이를 해결하기 위해서는
1. 해당 객체의 equals & hashcode를 재정의 하거나
2. Mocking 하는 함수의 인자를 any()로 설정해 어떤 값이 오더라도 원하는 응답을 반환하도록 한다.
'Spring' 카테고리의 다른 글
[Spring] Service에서 Service를 의존할까 Repository를 의존할까 (4) | 2023.06.04 |
---|---|
[Spring] 필터(filter)와 인터셉터(interceptor)의 특징과 차이점 (4) | 2023.05.08 |
[Querydsl] Unable to load class 'com.mysema.codegen.model.Type' 에러 해결 방법 (0) | 2023.01.12 |
[Spring] JPQL로 단일 Entity 찾을 시 에러 (No entity found for query) (0) | 2022.06.26 |
[Spring] JPA ManyToOne, OneToOne 매핑 된 객체를 가져올 때 문제점 (0) | 2022.06.17 |
- Total
- Today
- Yesterday
- 런칭 페스티벌
- 환경 별 로깅 전략 분리
- 8주차 회고
- 스프링 Logback
- 네트워크
- 알림기능개선기
- 우테코 회고
- 스프링 부트
- 파이썬
- 스프링 프레임워크
- 5주차 회고
- java
- 피움
- 프로젝트
- 우테코
- 백준
- jpa
- 피움 6주차 회고
- dm-zoned 코드분석
- 회고
- ZNS SSD
- 알림개선기
- 3차 데모데이
- CI/CD
- 2차 데모데이
- dm-zoned
- ZNS
- Spring
- 스프링MVC
- 팀프로젝트
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |