2주차 발자국

• 테스트 코드 작성

규모가 큰 운영 서비스 이거나 운영 기간이 오래 된 서비스 같은 경우 테스트 코드의 가치가 커진다.

메소드를 사용하는 다른 메소드들에서 의도하지 않은 결과가 나올 수 도 있어서 서비스 전체 기능에 미치는 사이드 이펙트들을 사전에 감지할 가능성이 올라간다.

• 어노테이션

  • @DataJpaTest @Entity 및 @Repository 어노테이션이 부여된 클래스들을 검색하 여 테스트 환경을 설정

  • @TestInstance 테스트 인스턴스의 라이프사이클을 지정

  • @BeforeAll 테스트 클래스 내의 모든 @Test 메소드 실행 전에 한 번 실행

  • @Test 테스트 메소드를 지정

  • @Autowired 의존성을 주입할 때 사용

  • @DisplayName 테스트 클래스나 메소드의 이름을 정의

• 리포지토리 성능 개선

  • N+1 문제

     

    대표적인 JPA의 단점, JPA에서는 먼저 부모 테이블에서 조회를 한 후 엔티티의 연관관계를 바탕으로 조회해온 데이터의 개수만큼 부모에 매핑된 자식 테이블의 데이터를 조회하기 위해 데이터베이스를 호출 그래서 N+1번의 쿼리가 사용

   

  • Fetch Type

    • Lazy : 런타임에서 연관관계 필드를 호출하는 경우 데이터베이스를 호출

    (부모 데이터가 100개가 조회되더라도, 단 1개의 부모 데이터에서만 자식 데이터를 사용할 경우 1개의 쿼리만 나감)

    • Eager : 부모 데이터를 조회하는 즉시 자식 데이터를 조회

    (실제로 자식 데이터를 사용하지 않더라도, 조회된 부모 개수만큼 쿼리가 나감)

   

  • Fetch Join : JPA에 의존하지 않고 직접 JPQL 쿼리를 보냄. Join을 활용해 한번에 부모와 자식 데이터를 조회

  (하지만 OneToMany, 또는 ManyToMany 관계의 자식 엔티티가 여러 개일 경우, 하나만 조인할 수 있다는 한계가 있음)

   

   

  • Batch Fetch Size : IN 절을 사용해서 여러 건의 데이터를 한번에 조회

  (1+N의 쿼리가 1+(N/batch_fetch_size) 정도의 수준으로 줄어든다고 할 수 있음.

   

  하지만 DBMS에 따라 IN 절의 파라미터 개수 제한이 있기도 하고, 한 번에 많은 데이터를 불러오는 것은 애플리케이션이나 데이터베이스 에 부담을 줄 수 있기 때문에 적절한 개수 설 정이 필요)

• 어노테이션

  • @Transactional 트랜잭션을 간편하게 열고 닫을 수 있게 해줌

    • rollbackFor 어떤 예외가 발생했을 때 롤백할지를 정의

    • readOnly 읽기 전용 트랜잭션으로 설정. JPA를 사용할 경우, 더티체킹 등을 수행하지 않기때문에 성능상

       

      이점이 있음

    • isoation 트랜잭션 고립 수준을 정의

    • @ExtendWith JUnit5에서 테스트 확장을 지원하는 어노테이션

    • @InjectMocks Mockito에서 테스트 대상이 되는 클래스에 인스턴스를 주입하기 위해 사용

    • @Mock Mockito에서 Mock객체를 생성할 때 사용

• 미션

   

  [미션 3] REST API 설계하기
  설계할때 네가지 기능(PUT, GET, POST, DELETE)를 주로 사용하는데 ERD를 설계한 후 API를 설계하니까 POST를 사용하려는 계획이 많아졌다. 처음부터 잘 생각하고 다시 작성해야할 것 같다. 너무 어렵게 생각하지말고 간단히 해서 완성을 해보는 것이 좋을 것 같다는 생각도 들었다.

   

   

이번주는 저번주보다 더 알아듣기 편해졌다. 1주차가 가장 힘든 것 같다.

2주차부터는 수업에 알아듣는 것이 많아졌다. 그리고 오타도 많아져서 에러가 좀 났었다. 오타확인 필수!