test/#38: OrderService 테스트 코드 작성

[dev2yup]

📌 Issue

• closed test: 주문 생성 및 조회 기능 테스트 코드 작성 #38

✍️ Summary

BDD 구조 테스트 작성

가독성을 위해 계층 구조는 2~3단계를 유지하였습니다.
Top Level (클래스): 테스트 대상 (예: OrderServiceTest)
1단계 (Nested 클래스): 테스트할 행위
2단계 (Nested 클래스): 행위가 일어나는 상황/조건
3단계 (메서드): 기대하는 결과/상태

주문 생성 테스트 ->

• 주문을_생성할_때
  • 유효한_요청이면
    • 주문과_결제가_정상_처리된다
    • 동일_멱등키로_재요청하면_기존_결제결과를_반환한다
  • 유효하지_않은_요청이면
    • 존재하지_않는_사용자면_예외가_발생한다
    • 존재하지_않는_옵션이면_예외가_발생한다
    • 결제금액이_옵션가격과_다르면_예외가_발생한다
    • 옵션이_판매중이_아니면_예외가_발생한다
    • 옵션의_재고가_없으면_예외가_발생한다
    • 같은_상품을_이미_주문했으면_예외가_발생한다
  • 결제승인이_실패하면
    • 주문은_생성되지_않고_실패_결제정보를_반환한다

주문 조회 테스트 ->

• 주문_내역을_조회할_때
  • 커서가_없을때
    • 기본_사이즈로_조회하면_10개까지_조회된다
    • 전체_건수가_size_이하면_hasNext_false_이고_next_cursor는_null이다
    • 전체_건수가_size를_초과하면_hasNext_true_이고_next_cursor는_마지막_항목이다
    • 주문이_없으면_빈_결과를_반환한다
  • 커서가_있을때
    • 커서를_전달하면_다음_페이지_데이터만_조회된다

📢 Notify

아직 주문 생성 테스트 코드는 작성 X

BDD 테스트 코드 작성 시 계층 나누기 팁
Describe-Context-It 패턴: BDD의 정석 패턴

• Describe: 무엇을 테스트하는가? (함수명, 클래스명)
• Context: 어떤 상황에서 테스트하는가? (상태, 조건)
• It: 테스트 결과는 무엇인가? (기대 동작)

BDD 테스트의 단점은 무엇이 있을까?

• 코드양의 증가
  메서드 하나를 테스트하려 해도 실제 검증 로직보다 구조를 잡기 위한 코드가 더 많아질 수 있음

• 깊은 계층 구조로 인한 인지 과부하
  3~4 단계의 계층 구조만 되어도 테스트의 맥락을 잃기가 쉬움, 상위 조건(@beforeeach)을 지속적으로 확인해야함

• 상위 계층 의존성
  @beforeeach에서 공통 데이터를 준비할 때 발생
  상위 계층의 조건 수정 시 하위 계층 모두에 영향을 끼쳐 유지보수가 어려워질 수 있음