inflearn logo
강의

강의

N
챌린지

챌린지

멘토링

멘토링

N
클립

클립

로드맵

로드맵

지식공유

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

Business Layer 테스트 (1)

비지니스 로직이 퍼시스턴스 계층에 침투하는 경우 관련해서 질문드립니다.

162

shk

작성한 질문수 19

0

안녕하세요

Business Layer 테스트 (1) 강의 시작 부분에서 Querydsl을 쓰거나 별도의 DAO를 사용하면서 비지니스 로직이 퍼시스턴스 계층에 침투하게 작성하는 경우가 있다고 하셨는데 좀 더 구체적인 예시를 들어주실 수 있나요?

그리고 요구사항이 복잡하여 엔티티를 가져오는 쿼리 역시 복잡해지는 경우, 이는 비즈니스 로직이 침투한 것으로 봐야할까요? 일반적인 CRUD 쿼리와 달리 특정 쿼리만 복잡하다면 추가적인 요소가 반영되었을 수도 있다 생각했고 따라서 이러한 경우를 비즈니스 로직의 개입으로 판단해야 하나 의문이 들어 질문 드립니다.

spring tdd jpa mockito 소프트웨어-테스트 junit5

답변 2

0

박우빈

안녕하세요, 김세희 님!

AI 인턴이 이미 잘 설명해준 것 같은데요. 조금 더 얹어서 설명하자면, 다음과 같은 상황을 예로 들 수 있겠습니다.

  • 비즈니스 조건에 따라 쿼리가 분기되는 경우

    • 비즈니스 레이어에서 판단해야 할 조건이 퍼시스턴스 레이어로 넘어와서, 판단 조건에 따라 A 혹은 B 쿼리가 달리 수행되는 경우

  • 비즈니스 레이어에서 수행해야 할 가공 처리를 퍼시스턴스 레이어에서 수행하는 경우

    • 쿼리 결과에 대한 기본값 보장 등의 간단한 가공 처리는 퍼시스턴스 레이어에서 담당할 수 있겠으나, 그 이상으로 비즈니스 레이어의 다른 데이터들을 받아서 추가로 가공한다던가, 도메인 정책을 기반으로 한 판단 및 가공하는 형태를 말합니다. 도메인 정책은 모두 비즈니스 레이어에서 집약적으로 수행되도록 해야 합니다.

그래서 쿼리 자체가 복잡해진다고 해서 비즈니스 로직이 침투한 것으로 보기는 어렵고, 도메인 정책에 입각하여 책임이 잘 나뉘어져 있는지 판단하시면 될 것 같아요.

도움이 되셨기를 바랍니다.
감사합니다. 🙂

0

shk

자세한 답변 감사합니다

0

인프런 AI 인턴

안녕하세요, 김세희 님. 인프런 AI 인턴입니다.

비즈니스 로직과 퍼시스턴스 계층의 분리가 중요한 이유는 각각의 계층이 본연의 역할에 초점을 맞추기 위해서입니다. 퍼시스턴스 계층은 데이터 저장 및 조회를 담당하고, 비즈니스 로직은 비즈니스 규칙을 처리합니다. 그런데 복잡한 쿼리를 작성하면서 이 두 계층이 엮이게 되면, 계층 간의 결합도가 높아져 유지보수가 어려워질 수 있습니다.

비즈니스 로직이 퍼시스턴스 계층에 침투하는 경우의 예시

  1. 조건 기반 데이터 추출:
    만약 데이터베이스 질의문에 비즈니스 로직의 세부적인 조건이 포함된다면 예를 들면, 특정 날짜 기간에 따라 고객 구매 패턴을 분석하기 위한 온갖 조건이 쿼리에 들어가는 경우 퍼시스턴스 레이어에 비즈니스 로직이 침투했다 말할 수 있습니다.

  2. 다양한 조건 조합에 따라 따로 결과를 반환:
    예를 들어 상품의 상태, 카테고리, 가격 등의 복잡한 조건에 따라 다른 처리 로직이 필요할 때, 이를 디비에서 모두 처리하는 대신 어플리케이션 레벨에서 처리하도록 하면 비즈니스 로직이 데이터를 정제하도록 할 수 있습니다.

복잡한 쿼리가 무조건 비즈니스 로직을 반영하는 것일까요?

  • 복잡한 쿼리와 비즈니스 로직:
    복잡한 쿼리가 무조건 비즈니스 로직의 침투를 의미하지는 않습니다. 데이터 통합이나 X(검색/탐색) 테이블 등에 필요한 복잡한 쿼리라면 퍼시스턴스 계층의 책임일 수 있습니다. 예를 들어 다수의 테이블 조인을 통한 데이터 집계 같은 작업은 데이터베이스 레벨에서 처리하는 것이 효율적일 수 있습니다.

  • 결정 기준:
    데이터의 저장과 검색을 넘어선 비즈니스 로직 (예: 계산, 논리 처리 등) 이 쿼리에 추가되어 있다면, 퍼시스턴스 레이어에서의 비즈니스 로직 개입으로 볼 수 있습니다.

질문자님의 상황에 맞는 해결 방법을 찾기 위해선, 어떤 로직이 어디서 효율적인지를 고려하여 결정을 내리는 것이 중요합니다. 이러한 개념에 대한 더 많은 예제와 논의를 원하신다면 이와 관련된 다음 유사한 링크를 참고하시기 바랍니다:

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

private 상수 테스트 관련 질문

0

82

1

void는 어떻게 테스트하나요..? void로 애초에 코딩하면 안되나요??

0

124

2

커버리지는 어떻게 활용하시는지 궁금합니다.

0

159

2

테스트 문서화 질문입니다

0

104

2

단위테스트 질문이 있습니다

0

95

2

컨트롤러는 모킹을 한 이유가 궁금합니다.

0

100

2

ERD 가장자리에 있는 도메인 테스트 질문

0

87

2

DTO 검증 필드에 대한 테스트 코드 작성은 어디까지?

0

132

2

OrderCreateRequest DTO에 대해서 궁금한점

0

101

2

고전파의 테스트 대역 사용 대상, 공유 의존성

0

154

2

계층 관련 질문이 있습니다.

0

137

3

'코틀린'에서는 빌더를 따로 쓰지 않는데, 이 때는 어떻게 test fixture를 만드시는지 궁금합니다

1

122

2

혹시 update 로직은 어떻게 테스트하나요? (@Setter?)

0

133

2

단위테스트와 통합테스트의 경계가 궁금합니다.

0

227

2

Service+Repository 통합테스트 관련 질문입니다.

0

149

2

OrderControllerDocsTest 작성 해봤는데요. 날짜 형식이 이상하게 나와요

0

183

2

test 용 .yml

0

89

2

throws Exception

0

78

2

카페키오스크 클래스 문의 ,,

0

87

2

Rest docs 문서용 테스트코드를 따로 작성해야 되나요?

0

172

2

테스트 코드에서 필요한 생성자

0

137

1

tearDown 순서

0

115

2

@Builder 생성자 private

0

135

2

@DisplayName gradle / intellJ

0

92

2