[워밍업 클럽 2기] Day 15 - 레이어 별 특징과 테스트 방법
워밍업 클럽 2기: Clean Code & Test Code의 Day 15 미션입니다. 🗄 Persistence(Data Access) 계층특징데이터 소스와의 상호작용을 담당한다데이터를 저장하고, 읽고, 업데이트하고 삭제하는 CRUD 작업을 수행한다데이터 JPA, JPQL, JDBC, 등의 여러 기술이 사용될 수 있다비즈니스 로직이 포함되면 안된다테스트 방법어느 기술을 사용하든, 신뢰성있는 테스트를 위해서 레포지토리의 테스트를 하는 것을 권장한다@SpringBootTest 또는 @DataJpaTest를 사용해서 데이터베이스에 CRUD 작업이 제대로 수행 되는지 테스트 한다@SpringBootTest와 @DataJpaTest의 차이를 알자 🚀 Business 계층특징핵심 비즈니스 로직을 처리하는 계층Persistence(Data Access)와의 상호작용을 통해 비즈니스 로직을 수행한다트랜잭션이 보장되어야 한다읽기 전용 트랜잭션과 CUD 트랜잭션(Command)을 적재적소에 적용하면 좋다트랜잭션의 종류에 따라 추후에 서비스를 나누는 것도 생각할 수 있다테스트 방법Persistence 계층까지 묶어서 통합 테스트를 하는 방식으로 테스트하거나, Persistence 계층을 모킹해서 단위 테스트 방식으로 테스트 한다.테스트 간 격리를 위해서 레포지토리를 초기화하는 로직이 필요하다@BeforeEach, @AfterEach, 등을 사용한 setUp이나 tearDown 메서드를 만들어서 레포지토리를 비운다@Transactional을 사용한다(서비스에 @Transactional이 붙어있지 않아도 동작한다. @Transactional의 효과에 대해 잘 파악하고 있어야 한다.) 💻 Presentation 계층특징클라이언트로 부터 입력을 받아서 비즈니스 계층으로 해당 요청을 보내는 계층요청을 제일 먼저 받는 계층입력 데이터에 대한 기본적인 검증을 수행한다Presentation 계층에서의 검증과 Business 계층에서의 검증을 분리해서 생각해야 한다Presentation 계층에서는 보통 형식적인 검증을 한다(예시: 필수 입력 값 검사, 데이터 타입 검사, null 검사, 빈 문자열 검사, 등...)Business 계층에서는 비즈니스 로직에 따른 도메인 유효성 검사가 이루어진다Business 계층으로 부터 결과를 받아서 클라이언트로 반환한다컨트롤러에서 사용하는 요청 DTO가 서비스 계층으로 침투하지 못하도록 컨트롤러 계층에서 서비스 전용 DTO로 변환하는 것을 권장한다(상황에 따라 다를 수 있을것 같다. 만약 받는 포맷이 변할 가능성이 거의 없다면, 그냥 컨트롤러의 DTO를 쭉 사용해도 괜찮지 않을까 생각이 된다.)테스트 방법Business, Persistence 계층을 모킹해서 테스트한다MockMvc 같은 도구를 사용해서 HTTP요청과 응답을 시뮬레이션 한다모킹을 위해서 Mockito 같은 프레임워크를 사용할 수 있다 🔍 참고Readable Code: 읽기 좋은 코드를 작성하는 사고법
