[워밍업 클럽 2기] Day 15 - 레이어 별 특징과 테스트 방법

워밍업 클럽 2기: Clean Code & Test Code의 Day 15 미션입니다.

🗄 Persistence(Data Access) 계층

특징
- 데이터 소스와의 상호작용을 담당한다
- 데이터를 저장하고, 읽고, 업데이트하고 삭제하는 CRUD 작업을 수행한다
- 데이터 JPA, JPQL, JDBC, 등의 여러 기술이 사용될 수 있다
- 비즈니스 로직이 포함되면 안된다
테스트 방법
- 어느 기술을 사용하든, 신뢰성있는 테스트를 위해서 레포지토리의 테스트를 하는 것을 권장한다
- @SpringBootTest 또는 @DataJpaTest를 사용해서 데이터베이스에 CRUD 작업이 제대로 수행 되는지 테스트 한다
- @SpringBootTest와 @DataJpaTest의 차이를 알자

특징
- 핵심 비즈니스 로직을 처리하는 계층
- Persistence(Data Access)와의 상호작용을 통해 비즈니스 로직을 수행한다
- 트랜잭션이 보장되어야 한다
  - 읽기 전용 트랜잭션과 CUD 트랜잭션(Command)을 적재적소에 적용하면 좋다
  - 트랜잭션의 종류에 따라 추후에 서비스를 나누는 것도 생각할 수 있다
테스트 방법
- Persistence 계층까지 묶어서 통합 테스트를 하는 방식으로 테스트하거나, Persistence 계층을 모킹해서 단위 테스트 방식으로 테스트 한다.
- 테스트 간 격리를 위해서 레포지토리를 초기화하는 로직이 필요하다
  - @BeforeEach, @AfterEach, 등을 사용한 setUp이나 tearDown 메서드를 만들어서 레포지토리를 비운다
  - @Transactional을 사용한다(서비스에 @Transactional이 붙어있지 않아도 동작한다. @Transactional의 효과에 대해 잘 파악하고 있어야 한다.)

특징
- 클라이언트로 부터 입력을 받아서 비즈니스 계층으로 해당 요청을 보내는 계층
- 요청을 제일 먼저 받는 계층
- 입력 데이터에 대한 기본적인 검증을 수행한다
  - Presentation 계층에서의 검증과 Business 계층에서의 검증을 분리해서 생각해야 한다
  - Presentation 계층에서는 보통 형식적인 검증을 한다(예시: 필수 입력 값 검사, 데이터 타입 검사, null 검사, 빈 문자열 검사, 등...)
  - Business 계층에서는 비즈니스 로직에 따른 도메인 유효성 검사가 이루어진다
- Business 계층으로 부터 결과를 받아서 클라이언트로 반환한다
- 컨트롤러에서 사용하는 요청 DTO가 서비스 계층으로 침투하지 못하도록 컨트롤러 계층에서 서비스 전용 DTO로 변환하는 것을 권장한다(상황에 따라 다를 수 있을것 같다. 만약 받는 포맷이 변할 가능성이 거의 없다면, 그냥 컨트롤러의 DTO를 쭉 사용해도 괜찮지 않을까 생각이 된다.)
테스트 방법
- Business, Persistence 계층을 모킹해서 테스트한다
- MockMvc 같은 도구를 사용해서 HTTP요청과 응답을 시뮬레이션 한다
- 모킹을 위해서 Mockito 같은 프레임워크를 사용할 수 있다