[01.29] 내일배움캠프[Spring] WIL-12

박상훈·2023년 1월 29일
0

내일배움캠프[WIL]

목록 보기
12/12

[01.29] 내일배움캠프[Spring] WIL-12

1. 지난 일주일

2. 어려웠던 점

  • JPQL 형식이 기존에 알던 SQL과 같은 듯 달라 조금 애먹었다.
  • join 쿼리를 두번 쓰는 구문에서 조금 애먹었다.
@Query(value = "SELECT new com.sparta.morningworkout.dto.search.CustomerListBySellerDto(u.username,p.nickname) " +
            "from Profile p join users u on p.id = u.id join CustomerRequest c on c.userId = u.id where u.username like %:keyword% AND c.sellerId=:sellerId")
    Page<CustomerListBySellerDto> findAllByCustomerName(long sellerId, String keyword, Pageable pageable);
  • TestCode의 작성 시 초반에 내가 뭘 테스트할 것인지 그 결과가 무엇인지 TDD,BDD가 무엇인지 약간의 혼돈이 있었음.

3. 배운 점

  • 연관관계를 전부 끊고 id 매핑으로 진행해서 다른 테이블과의 join이 불가피했는데,
    JPQL로 진행함으로써, 최적화 및 테이블을 조인하여 필요한 정보를 추출할 수 있었다.
  • UserSerivce코드를 작성하던 중 배운점.
  • @PostConstruct는 Test코드에서 먹지 않았다...
  • User의 정보가 올바른지 id 값으로 테스트하는 부분이 있었는데,
    User user = new User(...)으로 Mock객체가 아닌 진짜 객체를 만들어서 작업하니 ,
    검증 로직이 자동으로 돌아갔다.
    -> given ~ willReturn으로 주지 않아도 돌아갔다는 뜻..!
    -> 그래서 어려움이 존재했는데 , user객체 자체를 Mock객체로 선언하고, 검증 로직 부분을
    -> given ~ willReturn(true)로 부여하니 내가 원하는 테스트 결과를 얻을 수 있었다.
 @Test
    @DisplayName("상품 정보 수정 정상")
    void updateProduct()  {
        //given

        ProductUpdateRequestDto productUpdateRequestDto = new ProductUpdateRequestDto(7777);

        User user = mock(User.class);

        Product product = Product.builder().productName("computer").price(1000).build();
        //given(user.checkUser(anyLong())).willReturn(true);
        given(user.checkUser(anyLong())).willReturn(true);
        given(productRepository.findById(anyLong())).willReturn(Optional.ofNullable(product));
        //when

       String msg = productService.updateProduct(anyLong(),productUpdateRequestDto,user);
        //then
        assertThat(msg).isEqualTo("해당 제품의 가격이 업데이트 되었습니다");
    }

4. 느낀점

  • 과연 Test코드를 바탕으로 실무로직을 작성하는 TDD를 내가 할 수 있을까..?
  • 연관관계를 맺어서 효율적인 곳이 생긴다면 굳이 id매핑을 고집할 이유는,,?
profile
기록하는 습관

0개의 댓글