[TIL] Today I Lerned - 230111
2023. 1. 11. 21:09ㆍ기록/TIL
[TIL] Today I Lerned - 230111
230111 기록
프로젝트
기존 프로젝트에서 리팩토링 - 페이지 정렬 과정 및 test 코드에 시간을 들인 날
- 기존의 프로젝트에서 추가적으로 구현하는 사항이었지만 늦었지만 이번 리펙토링에서 다루게 되었다.
- 무수한 페이지를 한 번에 로딩하여 데이터를 사용하는 것보단, 해당 데이터들을 페이지 형식으로 정렬을 하여 사용자에게 출력을 하면 데이터의 소모량을 줄일 수 있다.
- 해당 과정을 페이지네이션, 페이징이라함
- 기존 강의 및 자료에서는 페이징을 설명할 때 Page <?> 인터페이스로 선언이 된 상태를 반환하였다
- 이번에 리팩토링을 하는 과정에서는 이전에 사용한 바와 같이 ResponseEntity를 이용하여 반환
- 다만 Service 계층에서 해당 내용을 이전에는 리스트를 사용해서 반환하였다면 이번에는 Page 형태로 반환
// 관심 상품 조회하기 - 강의에서 주어졌던 페이지네이션을 위한 코드
@GetMapping("/products")
public Page<Product> getProducts(
@RequestParam("page") int page,
@RequestParam("size") int size,
@RequestParam("sortBy") String sortBy,
@RequestParam("isAsc") boolean isAsc,
HttpServletRequest request
) {
// 응답 보내기
return productService.getProducts(request, page-1, size, sortBy, isAsc);
}
//-------------------------------------------------------------------------------------
// 리팩토링을 하면서 적용한 코드 - 기존의 방식에 들어있는 RequestParam 부분들을 한 곳으로 묶어 PageDto 생성
@GetMapping("/board/list")
public ResponseEntity getBoardList(
@RequestBody PageDto pageDto
) {
return ResponseEntity.status(HttpStatus.OK).body(boardService.getBoardAll(pageDto));
}
- ResponseEntity로 묶은 사유는 클라이언트에게 해당 자료의 페이징뿐만 아니라 Http 상태코드등의 메시지를 같이 전달해야겠다는 판단하에 Return 타입으로 지정하고 해당 값을 body에 넣어서 반환하였다.
- Page 형태로 반환하기 위해서는 해당 페이지가 어떤 형태의 값을 지녔는지 판단하고 JPA 쿼리에 넣어서 처리
- Page 내부 존재
- page - 몇 번째 page인지
- size - 몇 개의 글을 담을 것인지
- sortBy - 어떤 것을 기준으로 정렬할 건지
- isAsc - 오름차순, 내림차순
- 해당 내용을 같이 JPA 쿼리에 넣어주면 페이지 형태로 JPA에서 값을 가져올 때 사용
- Page 내부 존재
- 고민을 한 부분
- 우리가 DTO를 사용하는 이유는 해당 데이터가 온전한 상태로 밖으로 보이는 것을 막기 위해 한번 더 포장을 하는 것이다.
- 그럼 이때 예제의 경우 JPA에서 조회해서 가져온 데이터, 즉 entity를 바로 반환하는 방식으로 작성하였는데 그럼 이는 DTO가 필요 없는 과정이었나?라는 생각
- 같은 조의 조원분에게 물어보면서 이야기를 나눔. 해당 board라는 날것의 데이터를 변환하여 반환하는 방법 알게 됨
- Stream 사용.
- pageImpl이라는 구현체 이용
- 해당 생성자 부분에 board로 가져온 페이지를 stream을 사용하여 BoardResponseDto로 변환 후 리스트 한 뒤에 반환
return new PageImpl<>(boards.stream().map(BoardResponseDto::new).collect(Collectors.toList()))
TEST
- 같이 공부를 하면서 알게 된 동료분이 보내준 글에 있던 내용을 보면서 내가 알고 있는 내용을 정리하고 살을 붙이는 시간을 가질 수 있었다. 정말 감사합니다..
- 현재 공부하고 있는 부분은 TEST이다.
- 단순히 단위 테스트라고 생각을 하며, 내가 작성한 부분이 올바르게 돌아가며, 내가 값(시나리오)을 주입했을 때 해당 시나리오에 맞춰 원하는 반환값을 도출하는 과정을 공부하고 있었다.
- 현재 단위 테스트의 경우 각 레이어를 침범하지 않으면서 제 역할을 하는지 테스트하는 것에 포커스를 두고 작성 중
- 다만 Spring Rest Docs에 들어가는 경우 controller 테스트 코드가 필요하지만 현재 그 정도의 테스트 코드를 작성하는데 어려움을 겪는 중. - 문서화 이번주 내로 꼭 도전하고 처리해 볼 예정
- BDD - Behavior- Driven Development
- (출발) Given / (변화가 생긴 시점) When / (완료) Then의 구조를 가지며 아까 언급한 시나리오와 return 값을 테스트코드로 뽑아내는 과정
- BDD의 경우 기존의 Mockito가 아닌 BDDMockito라는 Mockito를 상속한 클래스를 사용
- 시나리오에 맞게 테스트 코드에 Given / when의 값이 들어갈 수 있는 역할
- 기존의 경우 실제 when메서드를 사용하여 값을 예상하는 과정이 given에 들어가는 부분이 존재하였다. 그러나 해당 BDDMockito를 사용하면 이런 불편한 가독성을 해치는 부분의 사용을 지양할 수 있는 것을 알 수 있었다.
'기록 > TIL' 카테고리의 다른 글
[TIL] Today I Lerned - 230113 (0) | 2023.01.14 |
---|---|
[TIL] Today I Lerned - 230112 (0) | 2023.01.12 |
[TIL] Today I Lerned - 230110 (0) | 2023.01.10 |
[TIL] Today I Lerned - 230109 (0) | 2023.01.09 |
[TIL] Today I Lerned - 230106 (0) | 2023.01.06 |