Layered Architecture

https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html

https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html

가장 잘알려진 아키텍쳐 패턴으로서 각 티어별로 테스트코드에 대한 필요를 정리하였다.

각 레이어의 특징과 어떻게 테스트를 하면 좋을지에 대해 개인적인 생각을 정리하려 한다.

Presentation Layer

하는 일 : 요청을 받아 그 요청을 Business Layer에 전달한다

검증하고자 하는 것 : 유효한 요청인가

그 위의 상위적인 Business 혹은, 동작 부분에 대한 것은 각 부분에 Business Layer에 위임을 하면 된다.

중요한 것은, 이렇게 분리된 아키텍쳐 패턴은 각 아키텍쳐간 분리와 책임을 명확하게 하기 위함이다.

@WebMvcTest(controllers = OrderController.class)
class OrderControllerTest {
    @Autowired
    private MockMvc mockMvc;

    @Autowired
    private ObjectMapper objectMapper;

    @DisplayName("주문 요청이 들어오면 주문을 생성한다.")
    @Test
    void createOrder() throws Exception {
        // given
        OrderCreateRequest orderCreateRequest = OrderCreateRequest.builder()
                .productNumbers(List.of("001"))
                .build();

        // when // then
        mockMvc.perform(post("/api/v1/orders/new")
                        .content(objectMapper.writeValueAsBytes(orderCreateRequest))
                        .contentType(MediaType.APPLICATION_JSON)
                )
                .andDo(print())
                .andExpect(status().isOk())
                .andExpect(jsonPath("$.code").value("200"))
                .andExpect(jsonPath("$.status").value("OK"))
                .andExpect(jsonPath("$.message").value("OK"));
    }  

코드를 작성할 때는 @WebMvcTest 를 사용하였다.

모든 비즈니스 로직을 수행할게 아니기 때문에 특정한 결과에 이렇게 될거라고 낙관적으로 판단하고, mock테스트를 수행한다.

mock테스트는 해피테스트라 별로 안좋아하는데, 이 경우는 비즈니스 레이어를 테스트하는게 아닌 응답을 테스트 하는 것이기 때문에 응답에 대한 유효성을 검증한다.

따라서, 필요하다면 DTO에 응답에 대한 유효성을 반환하는 SpringValidation 같은 검증 코드를 사용하는 것도 유용하다

Business Layer

하는 일 : Presentation Layer에서 전달받은 응답 값으로 비즈니스 로직을 수행하고, 필요시 Persistance Layer에 접근하여 로우 레벨의 데이터를 얻는다.

검증하고자 하는 것 : 비즈니스 로직이 성공적으로 수행되는가