[인프런 워밍업 클럽 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