👣3주 차 발자국

Practical Testing: 실용적인 테스트 가이드

✅ 강의 요약

섹션 6. Spring & JPA 기반 테스트

Layered Architecture

• 단점 : 기술에 대한 강결합

  
  
  통합테스트

• 단위테스트 만으로는 기능 전체의 신뢰성을 보장할 수 없다. (여러 모듈 및 여러 객체가 협력하기에)

   

• 여러 모듈이 협력하는 기능을 통합적으로 검증하는 테스트

  
  
  Spring / JPA 훑어보기 & 기본 엔티티 설계

   

• IoC (Inversion of Control)

  • 객체의 생성과 소멸, 생명주기 관리를 제 3자가 하는 원리

• DI (Dependency Injection)

  • 필요한 객체를 직접 생성하는 것이 아닌 외부에서 생성해 주입하는 것

  • IoC이 DI로 실현된다.

• AOP (Aspect Oriented Programming)

  • 비즈니스 흐름과 관계없는 공통 기능 (트랜잭션, 로깅 등) 을 분리해 모듈화 시키는 것을 의미

  • 스프링에서는 Proxy형태로 제공

• ORM (Object-Relational Mapping)

  • 객체 지향 패러다임과 관계형 DB 패러다임의 불일치를 해결

     

• JPA (Java persistence API)

  • Java 진영의 ORM 기술 표준

  • JPA - 인터페이스, 구현체 - Hibernate (대표적으로 사용됨)

  • Spring에서는 JPA를 한번 더 추상화한 Spring Data JPA 형태로 제공

  • 주로 QueryDSL과 같이 사용됨

     

   

  Persistence Layer 테스트

  
  
  @DataJpaTest

• JPA 관련 컴포넌트만 테스트할 때 사용하는 전용 어노테이션

• @SpringBootTest보다 가볍다.

• @Transactional이 있어 롤백이 된다.

• 그치만 선호하지 않는다.

  
  
  Persistence Layer

• Data access의 역할만 해야한다.

• Data의 CRUD에만 집중한 레이어.

  
  
  Business Layer 테스트

• 비즈니스 로직을 구현하는 역할

• Persistence Layer와의 상호작용을 통해 개선 (통합적 테스트)

• 트랜잭션을 보장해야 한다.
  

@WebMvcTest

• Presentation Layer에 대한 단독 테스트시 사용하는 어노테이션
  
  @Transactional(readOnly = true)

• 읽기 전용

• JPA에서는 스냅샷 저장, 변경감지가 일어나지 않아 성능 향상

• read only값을 보고 DB의 endpoint를 분리할 수 있다. (true일 경우, read 전용 DB로 보낸다.)

• 구분을 잘 하는 것이 중요하다.

  • readOnly = true 구분이 누락될 수 있기에 아래 방법을 사용.

  • service class 상단에 readOnly = true를 걸고, CUD 작업이 있다면 메서드 단위에 @Transactional을 건다.
    

CQRS

• 읽기(조회)와 쓰기(명령)의 책임을 분리하는 소프트웨어 아키텍처 패턴

• Command(CUD) 와 Query(Read) 의 책임을 분리하자. (read가 훨씬 많이 일어난다.)

   

• 성능 최적화, 비지니스 로직의 분리, 장애 격리를 할 수 있다.

✅ 강의 회고

WebMvcTest의 사용과 Transactional(readOnly = true)의 중요성을 알게 되었다.

그리고 @SpringBootTest는 데이터 클랜징이 필요 하기 때문에 클랜징 때문에 일어나는 문제를 유의해서 봐야하는걸 배웠다. 데이터 세팅에 손이 많이 가기 때문에 테스트가 귀찮다고 느껴지는 것이 아닌가 싶었다.

✅ 미션 과정 & 회고

미션 PR - link

우선 스터디 카페 이용권 선택 시스템을 기반으로 미션을 진행했다.

강의 내용처럼 @DisplayName을 최대한 자세히 작성하려고 했고, 미션 조건처럼 3개 이상의 서로 다른 클래스를 만족하기 위해 기능이 다른 클래스를 선택해 작성했다.

그리고, BDD (given/when/then) 스타일을 따라 작성했다.

강의 내용처럼 테스트가 '성공한다' , '실패한다' 의 의미를 포함하지 않게(테스트의 현상을 포함하지 않게)
DispayName을 작성하려 했고, 최대한 도메인에 관련된 이름을 넣어서 표현했다.

TDD 방식으로 작성한 테스트가 아니기 때문에 해피케이스만 작성된 것 같다. 아무래도 이에대한 보완은 중간점검때 확인해 봐야 할 것 같다.

강의 - Practical Testing: 실용적인 테스트 가이드