[인프런 워밍업 클럽 3기 BE 클린코드 & 테스트 스터디 ] 발자국 3주차

3주차

[섹션 6]

레이어드 아키텍처(Layered Architecture)와 테스트
- Presentation Layer, Business Layer, Persistence Layer로 분리
- 관심사의 분리
- 통합 테스트
  - 여러 모듈이 협력하는 기능을 통합적으로 검증하는 테스트
  - 일반적으로 작은 범위의 단위 테스트만으로는 기능 전체의 신뢰성을 보장할 수 없다.
  - 풍부한 단위 테스트 & 큰 기능 단위를 검증하는 통합 테스트
Persistene Layer 테스트
- @SpringBootTest
  - spring boot의 모든 빈들을 다 주입한다.
- @DataJpaTest
  - JPA관련 빈들만 주입한다.
  - 속도가 @SpringBootTest보다 빠르다.
Business Layer 테스트
- 비즈니스 로직을 구현하는 부분
- Persistence Layer와의 상호작용을 통해 비즈니스 로직을 전개시킨다.
- 트랜잭션을 보장해야 한다.
- @DataJpaTest는 @SpringBootTest와 다르게 @Transactional이 자동으로 걸려있다.
  - 데이터 롤백이 기본적으로 된다.
- @SpringBootTest에 @Tracnsactional을 걸었을 때 주의할 점
  - 서비스 클래스에서 @Transactional이 없어도 Test시에 걸어줬기 때문에 테스트가 통과될 수 있다.
- @AfterEach를 통해서 repository들을 초기화할 수 있다.
  - @Transactional을사용하면 deleteAll 등 초기화 단계를 설정하지 않아도 된다.
- deleteAll과 deleteAllInBatch의 차이
  - deleteAll은 내부적으로 한 건씩 개별 삭제한다.
  - 연관 관계 테이블을 먼저 지우지 않아도, 개별 삭제할 때 같이 지운다.
  - deleteAllInBatch는 개별 삭제가 아닌 bulk query를 사용하여 한 번에 삭제한다.
  - 단, 연관 관계 테이블을 먼저 삭제해야지, 외래키 제약 조건에 어긋나지 않는다.
Presentation Layer 테스트
- 동시성 이슈
  - 생성 함수에서는 동시성을 고려해줘야 한다.
  - 함수 호출 빈도가 낮으면, id에 unique 제약 조건을 걸고, 실패 시 재시도하는 로직 추가
  - 함수 호출 빈도가 높으면, UUID 같은 것으로 대체
- 서비스단에 readOnly = true를 base로 사용
  - cud 작업일 때는 @Transactioal을 메서드 위에 선언해서, readOnly가 되지 않게끔 작동
- CQRS - command / read를 분리
  - read 부분은 조회 전문 repository나 로직을 구현 가능
  - command는 복잡한 로직을 담당할 수 있다.

Day 11 미션

https://github.com/taeyeongKims/readable-code/tree/main/src/test/java/cleancode/studycafe/tobe/model

출처 : https://www.inflearn.com/course/practical-testing-%EC%8B%A4%EC%9A%A9%EC%A0%81%EC%9D%B8-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EA%B0%80%EC%9D%B4%EB%93%9C/dashboard