테스트 대역폭 늘리기 - Yun Blog | 기술 블로그 about blog-comment HOT 4 OPEN

@wannte

결론부터 말씀드리면 OrderService 테스트 코드는 필요하다고 생각합니다.

OrderService에서 진행했던 핵심 비즈니스 코드는 OrderServiceSupport POJO 객체로 위임했는데요. 이렇게 하여 OrderServiceSupport 쪽에서 테스트 대역폭(많은 테스트 케이스를 커버하는) 테스트를 진행하고 OrderService에서는 그렇게 복잡하진 않지만 최종 인프라스트럭처까지 문제없는지 검증을 진행하면 된다고 생각합니다.

물론 여기서 OrderService에 대한 테스트에 대한 커버리지를 어디까지 해야 하는지에 대한 부분이 사람마다 다를 수 있다고 생각 하지만 제 개인적인 의견은

    fun order(
        productId: Long,
        orderDate: LocalDate,
        orderAmount: BigDecimal,
        shopId: Long,
        couponCode: String?
    ): String {
        // 상품 정보는 Elasticsearch에서 조회
        val product = productQueryService.findById(productId) //(1)
        // 환율 정보는 Redis에서 조회
        val exchangeRateResponse = exchangeRateClientImpl.getExchangeRate(orderDate, "USD", "KRW") //(2)
        // 쿠폰 정보는 MySql에서 조회
        val coupon = couponQueryService.findByCode(couponCode) //(3)
        // 가맹점 정보는 MySql에서 조회
        val shop = shopQueryService.findById(shopId) //(4)
        

        // 복잡한 로직... OrderServiceSupport 객체로 위임 //(5)
        val order = OrderServiceSupport().order(...)

        val order = save(order)

        return order.orderNumber
    }

해당 코드에 대해서 테스트 코드를 작성해야 한다면 복잡한 비즈니스 로직은 (5) 객체에서 진행했을 것이고

이제 인프라적인 테스트 코드는 (1) ~ (4) 테스트에 해당하는 코드는 이미 해당 객체에서 전부 진행했을 것이기 때문에 여기에서는 정상적으로 등록되는지 케이스 1~2 가지 케이스에 대해서 진행할 거 같습니다.

정리해서 말씀드리면 각 객체에서 본인의 책임에 대한 단위 테스트를 충분히 작성을 하고, 그것을 조합하여 시용하는 코드에서는 단위 테스트를 믿고 동일한 테스트는 특별한 이유가 없으면 진행하지 않는 게 좋다고 생각합니다. 본문에서도 말했듯이 중요한 건 내가 테스트하고자 하는 객체, 메서드의 주요 관심사가 무엇인지 명확하게 하고, 그 관심사 외에는 해당 객체의 직접적인 책임이 아니라고 생각합니다.

from blog-comment.

한 가지 질문이 드립니다.!

Support 객체로 위임하여, repository와의 의존성을 끊어서 테스트를 진행할 수 있다고 생각하는데요,

이것보다 하나의 layer 위의 계층의 테스트에 대해서는 어떻게 생각하시는 지 궁금합니다.
예를 들어, Support를 도입한 이후의 OrderService에 대한 테스트는 불필요한 테스트 코드일까요?

from blog-comment.

위의 코드에서 쿠폰 정보 조회를 복잡한 로직 중에 조건부로 실행해야한다면 어떻게 해야할까요..?
예를 들면 상품이름에 "할인"이 들어가있고 가맹점 정보에서 "할인" 조건을 활성화 한 경우?

from blog-comment.

@Jiinwoo
문의하신 내용이 POJO 객체에서 복잡한 로직을 조합해 봤더니 추가적으로 할인 조건에 해당하기 때문에 쿠폰 정보가 필요해진 경우에 대해서 문의하신 걸로 이해했습니다.

POJO 객체에서 처리하다 보니 추가적으로 쿠폰 정보가 필요하게 된 경우 인프라스트럭처에서 추가적인 조회가 어려운 상황인 거 같은데요. 제가 생각하는 방법은 복잡한 쿠폰 필요 로직을 사전에 검사할 수 있는 POJO 로직을 통해 쿠폰 필요 여부를 검사한다.

class CouponSupport {
    fun needCoupon(...) : Boolean {
    // ... 복잡한 쿠폰 필요 여부 확인
   }
}

쿠폰 필요 여부 서포트 객체를 만들고 필요 여부를 확인하고 필요하다고 판단되면 OrderServiceSupport의 order 객체에 쿠폰 객체를 넘겨주는 방식으로 진행할 거 같습니다. 복잡한 주문 로직을 처리하는 입장에서는 더 이상 쿠폰의 필요 여부에 대한 복잡한 로직을 CouponSupport 객체에 위임 처리합니다.

from blog-comment.