미션

Layered Architecture 구조의 레이어별 테스트 작성법을 알아보았습니다.

레이어별로 1) 어떤 특징이 있고, 2) 어떻게 테스트를 하면 좋을지, 자기만의 언어로 다시 한번 정리해 볼까요?

🛢Persistence Layer

DB와 직접 상호작용하는 레이어로,

Spring Data JPA의 쿼리 메서드나 커스텀 네이티브 쿼리를 정의합니다.

Spring Data JPA의 기본 메서드로 해결되지 않는 요구사항이 생기면,

Repository에 쿼리 메서드를 직접 정의하고 이에 대한 테스트 코드를 작성해줘야합니다.

테스트 방식

@SpringBootTest를 사용해 통합 테스트를 수행합니다.

Repository 하나만 테스트하는 경우가 많기 때문에

통합 테스트지만 단위 테스트에 가까운 성격을 갖습니다.

주의할 점

요구사항이 바뀌거나 추가되는 경우가 잦기 때문에,

쿼리를 추가할 때마다 누락 없이 테스트를 작성해줘야 합니다.

⚙Business Layer

비즈니스 로직을 처리하는 핵심 레이어로, Persistence Layer에 의존합니다.

비즈니스 로직은 트랜잭션을 전제로 하기 때문에,

@Transactional을 통해 트랜잭션 경계를 명확히 지정해줘야 원하는 동작을 보장할 수 있습니다.

테스트 방식

@SpringBootTest로 통합 테스트를 진행합니다.

Repository를 활용해 데이터를 저장하고,

이를 기반으로 비즈니스 로직이 의도대로 동작하는지 검증합니다.

주의할 점

요구사항 추가에 따라 도메인 로직과 Repository가 자주 변경되는데,

Business 테스트에 앞서

도메인 로직에 대한 단위 테스트와 Persistence 테스트를 먼저 작성해줘야합니다.

동시성 이슈가 발생할 수 있는 경우,

멀티스레드를 고려한 동시성 테스트도 고민이 필요합니다.

💻Presentation Layer

API로 전달받은 Request 값의 유효성 검증을 수행합니다.

입력값 자체의 예외(타입 에러 등)와 비즈니스 예외를 명확히 구분해야 합니다.

테스트 방식

@WebMvcTest로 통합 테스트를 진행합니다.

@MockitoBean으로 Service를 주입하여 실제 구현을 대체합니다.

MockMvc를 통해 API 요청을 시뮬레이션하고, JSON 응답 구조와 상태 코드를 검증합니다.

Spring bean Validation을 활용해 Request DTO에 유효성 검증 로직을 추가하고 테스트합니다.

주의할 점

Presentation Layer는 Business Layer에 의존하지만,

Business Layer는 Presentation Layer를 몰라야 확장 가능한 구조가 됩니다.

따라서 Request DTO는 컨트롤러용과 서비스용으로 분리하는 것이 좋습니다.

JSON 역직렬화 시 getter와 기본 생성자는 필수입니다.

만약 없다면 Jackson 라이브러리를 사용할 수 없으니 반드시 추가해줍니다.

미션 후기

레이어마다 관심사와 책임이 명확히 분리되어 있기 때문에,

테스트 전략도 각 레이어의 특성에 맞게 달라져야 한다는 점이 인상 깊었습니다.

단위 테스트와 통합 테스트의 구조를 익히고 나니,

다음 단계인 인수 테스트는 어떻게 설계되고 진행되는지 궁금해집니다!

강의

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