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

💡 본 게시글은 박우빈님의 'Practical Testing: 실용적인 테스트 가이드' 강의를 공부하고, 이에 대해 정리한 내용입니다.

---

들어가며

 소프트웨어 개발자로서 경력을 쌓아가는 과정에서, 코드의 품질과 유지보수성에 대해 많은 고민을 하게 되었습니다. 개발 초기에는 주어진 시간 안에 기능을 완성하는 것이 중요했기 때문에 테스트의 중요성을 간과하고, 기능 구현에만 집중하였습니다. 하지만 프로젝트가 복잡해지고 규모가 커지면서, 기능 구현 후에 발생하는 예기치 않은 버그와 문제들이 점점 더 빈번해졌습니다. 이러한 경험을 통해 테스트 코드의 필요성을 절감하게 되었습니다. 그래서 저는 좀 더 체계적인 테스트 코드 작성과 TDD(Test Driven Development)에 대해 구체적으로 학습하고 싶었습니다.

---

Section 01. 테스트 코드의 필요성

1. 테스트 코드를 작성하지 않는다면?

• 귀찮은 작업: 테스트 코드는 기본적으로 귀찮은 작업이다. 실무에서는 짧은 시간 안에 기능 구현만 하기에도 벅찬데, 테스트 코드를 작성하기가 쉽지 않다.
• 테스트 소홀: 테스트의 필요성을 명확히 이해하지 못하면, 이 작업을 소홀히하고 무시하는 경향이 생길 수 있다.
• 수동 테스트의 한계: 테스트 코드가 없는 환경에서는 새로운 기능을 추가하거나 코드를 수정할 때 기존 코드가 여전히 정상 작동하는지 확인하기 위해 사람이 직접 수동으로 테스트해야 한다.
• 확장성과 인력 문제: 프로덕션 코드는 시간이 지날수록 점점 더 확장하게 되는데, 그때마다 테스트 인력을 무한정 늘릴 수는 없다.
• 누락된 테스트 케이스: 사람이 수동으로 테스트를 하다 보면 누락되는 케이스가 발생할 수 있고, 이는 치명적인 결함으로 이어질 수 있다.
• 커버리지 부족: 소프트웨어가 커지는 속도를 따라잡지 못하게 되고, 기능들도 서로 겹치면서 기존에 테스트했던 영역을 또 테스트하게 되면서 커버할 수 없는 영역이 발생하게 된다.
• 경험과 감에 의존: 프로젝트를 오래 했던 사람들 또는 개발 및 테스트를 오래 했던 사람들의 경험과 감에 의존하게 된다.
• 피드백 지연: 사람이 테스트를 하다 보니 시간이 오래 걸려 피드백이 늦어지고, 버그 수정 과정이 느려진다. 이는 유지보수를 어렵게 하고, 소프트웨어의 신뢰도를 낮춘다.

---

2. 테스트 코드가 필요한 이유

• 빠른 피드백: 테스트 코드를 통해 내가 개발한 기능이 의도한 대로 동작하는지 빠른 피드백을 받을 수 있다.
• 자동화 및 신뢰성: 기계가 검증할 수 있도록 자동화를 통해 소프트웨어에 대한 안정감과 신뢰감을 얻을 수 있다.
• 소프트웨어 커버리지: 테스트 코드를 잘 추가하면, 커지는 소프트웨어의 프로덕션 코드를 테스트 코드가 계속 커버할 수 있다.
• 유지보수 용이성: 올바른 테스트 코드를 작성하면 프로덕션 코드의 안정성을 제공하며 유지보수하기 쉬워진다.
• 비용 절약: 자동화를 통해 빠른 시간 안에 버그를 발견할 수 있고, 수동 테스트에 드는 비용을 절약할 수 있다.
• 빠른 변화 지원: 소프트웨어의 빠른 변화를 지원할 수 있다.
• 팀 내 공유 지식: 고민했던 것들을 코드로 녹여내면, 팀 내 공유 지식이 되어 팀원들의 집단 지성을 팀 차원의 이익으로 승격시킬 수 있다. 이는 ‘가까이 보면 느리지만, 멀리 보면 가장 빠르다’로 표현될 수 있다

---

3. 결론

1) 테스트 코드를 작성하지 않는다면?

• 변화가 생기는 매순간마다 발생할 수 있는 모든 Case를 고려해야 한다.
• 변화가 생기는 매순간마다 모든 팀원이 동일한 고민을 해야 한다.
• 빠르게 변화하는 소프트웨어의 안정성을 보장할 수 없다.

 

2) 테스트 코드가 병목이 된다면?

• 프로덕션 코드의 안정성을 제공하기 힘들어진다.
• 테스트 코드 자체가 유지보수하기 어려운, 새로운 짐이 된다.
• 잘못된 검증이 이루어질 가능성이 생긴다.

 

3) 올바른 테스트 코드란?

• 자동화 테스트로 비교적 빠른 시간 안에 버그를 발견할 수 있고, 수동 테스트에 드는 비용을 크게 절약할 수 있다.
• 소프트웨어의 빠른 변화를 지원한다.
• 팀원들의 집단 지성을 팀 차원의 이익으로 승격시킨다.
• 가까이 보면 느리지만, 멀리 보면 가장 빠르다.

---

Section 02. 단위 테스트

※ 초간단 카페 키오스크 시스템 개발과 테스트 코드 작성

1. 개발 환경

• IDE: IntelliJ Ultimate
• Java: 11
• Framework: Spring Boot 2.7.7
• Build Tool: Gradle & Groovy
• Dependencies: Spring Web, Thymeleaf, Spring Data JPA, H2 Database, Lombok, Validation
• Testing: Junit5, AssertJ

---

2. 단위 테스트란?

• 정의: 단위 테스트는 작은 코드 단위를 독립적으로 검증하는 테스트를 의미한다. 여기서 작은 코드는 클래스 혹은 메서드를 의미한다.
• 특징: 단위 테스트는 검증 속도가 빠르고 안정적이다.

---

3. 수동 테스트와 자동화 테스트

1) 수동 테스트

• 정의: 개발자가 직접 기능을 실행하고 결과를 검증하는 테스트 방식.
• 장점:
  • 간단한 기능에 대해서 빠르게 검증할 수 있다.
  • 직관적이고 즉각적인 피드백을 얻을 수 있다.
• 단점:
  • 반복적이고 시간이 많이 소요된다.
  • 테스트 과정에서 실수가 발생할 가능성이 높다.
  • 대규모 프로젝트에서는 비효율적이다.

2) 자동화 테스트

• 정의: 테스트 코드를 작성하여 자동으로 테스트를 실행하고 결과를 검증하는 테스트 방식.
• 장점:
  • 반복적인 테스트를 자동으로 수행하여 시간을 절약할 수 있다.
  • 일관된 결과를 제공하며, 인간 오류를 줄일 수 있다.
  • 대규모 프로젝트에서 효율적이며 유지보수가 용이하다.
• 단점:
  • 초기 설정과 테스트 코드 작성에 시간이 소요된다.
  • 테스트 코드 유지보수가 필요하다.

---

4. Junit5와 AssertJ

• Junit5: 단위 테스트를 위한 테스트 프레임워크이다. (참고 - 공식문서)
• AssertJ: 테스트 코드 작성을 원활하게 돕는 테스트 라이브러리이다. 풍부한 API와 메서드 체이닝을 지원한다. (참고 - 공식문서)

---

5. 테스트 케이스 세분화하기

1) 요구 사항: 한 종류의 음료 여러 잔을 한 번에 담는 기능

• 질문하기: 암묵적이거나 아직 드러나지 않은 요구 사항이 있는지 항상 염두하고 고민해봐야 한다.
• 해피 케이스와 예외 케이스 도출: 경계값 테스트를 통해 해피 케이스와 예외 케이스를 작성할 수 있다.

---

6. 예시 테스트 케이스

• 해피 케이스: addSeveralBeverages 메서드는 하나의 종류인 아메리카노에 2개를 담는 테스트
• 예외 케이스: addZeroBeverages 메서드는 하나의 종류인 아메리카노에 0개를 담았을 때 예외가 발생하는 테스트

---

7. 경계값 테스트

• 정의: 입력 값의 경계에서 발생할 수 있는 오류를 찾기 위해 경계 조건을 테스트하는 방식.
• 목적: 입력 값의 최솟값, 최댓값, 경계 근처의 값들을 테스트하여 시스템이 올바르게 동작하는지 검증한다.
• 예시:
  • 어떤 정수 값이 3 이상일 때 특정 조건을 만족한다고 가정하면, 3 이상에 대한 해피 케이스와 3 미만에 대한 예외 케이스를 작성한다.
  • 경계값 테스트는 범위(이상, 이하, 미만, 초과), 구간, 날짜 등을 테스트할 때 유용하다.

---

8. 테스트하기 어려운 영역

1) 요구사항: 가게 운영 시간(10:00 ~ 22:00) 외에는 주문을 생성할 수 없다.

• 시간 의존성 문제 해결: 주문 생성 로직에 시간 관련 부분을 외부에서 받아올 수 있도록 변경한다.
• 외부 시간 데이터 수신: 테스트 시에는 원하는 시간을 통해 검증하고, 프로덕션 코드에서는 현재 시간을 인자로 주어 동작할 수 있다.

 

2) 코드 예시

@Getter
public class CafeKiosk {

    public static final LocalTime SHOP_OPEN_TIME = LocalTime.of(10, 0);
    public static final LocalTime SHOP_CLOSE_TIME = LocalTime.of(22, 0);

    // 변경 전
    public Order createOrder() {
        LocalDateTime currentDateTime = LocalDateTime.now();
        LocalTime currentTime = currentDateTime.toLocalTime();
        if (currentTime.isBefore(SHOP_OPEN_TIME) || currentTime.isAfter(SHOP_CLOSE_TIME)) {
            throw new IllegalArgumentException("주문 시간이 아닙니다. 관리자에게 문의하세요.");
        }

        return new Order(currentDateTime, beverages);
    }

    // 변경 후: 외부에서 시간 데이터를 받아올 수 있도록 변경
    public Order createOrder(LocalDateTime currentDateTime) {
        LocalTime currentTime = currentDateTime.toLocalTime();
        if (currentTime.isBefore(SHOP_OPEN_TIME) || currentTime.isAfter(SHOP_CLOSE_TIME)) {
            throw new IllegalArgumentException("주문 시간이 아닙니다. 관리자에게 문의하세요.");
        }

        return new Order(currentDateTime, beverages);
    }
}

 

3) 테스트 코드 예시

class CafeKioskTest {

    @Test
    void createOrder() {
        CafeKiosk cafeKiosk = new CafeKiosk();
        Americano americano = new Americano();

        cafeKiosk.add(americano);

        Order order = cafeKiosk.createOrder();

        assertThat(order.getBeverages()).hasSize(1);
        assertThat(order.getBeverages().get(0).getName()).isEqualTo("아메리카노");
    }

    @Test
    void createOrderWithCurrentTime() {
        CafeKiosk cafeKiosk = new CafeKiosk();
        Americano americano = new Americano();

        cafeKiosk.add(americano);

        Order order = cafeKiosk.createOrder(LocalDateTime.of(2023, 11, 30, 10, 0));

        assertThat(order.getBeverages()).hasSize(1);
        assertThat(order.getBeverages().get(0).getName()).isEqualTo("아메리카노");
    }

    @Test
    void createOrderOutsideOpenTime() {
        CafeKiosk cafeKiosk = new CafeKiosk();
        Americano americano = new Americano();

        cafeKiosk.add(americano);

        assertThatThrownBy(() -> cafeKiosk.createOrder(LocalDateTime.of(2023, 11, 30, 9, 59)))
                .isInstanceOf(IllegalArgumentException.class)
                .hasMessage("주문 시간이 아닙니다. 관리자에게 문의하세요.");
    }
}

---

9. 테스트하기 어려운 영역

• IN: 관측할 때마다 다른 값에 의존하는 코드 - 현재 날짜/시간, 랜덤 값, 전역변수/함수, 사용자 입력
• OUT: 외부 세계에 영향을 주는 코드 - 표준 출력, 메시지 발송, 데이터베이스에 기록하기

---

10. 테스트하기 쉬운 코드

• 특징: 외부 세계와 단절된 함수형 프로그래밍의 순수 함수(pure functions)
  • 같은 입력에는 항상 같은 결과
  • 외부 세상과 단절된 형태

---

11. Lombok 사용 가이드

1) Lombok이란?

• 정의: Lombok은 자바 애플리케이션에서 반복되는 코드 작성을 줄여주는 라이브러리이다.
• 장점:
  • Getter, Setter, Constructor, ToString 등의 메서드를 자동으로 생성해준다.
  • 코드 가독성을 높이고 유지보수를 용이하게 한다.

2) 주요 어노테이션

• @Getter: 모든 필드의 getter 메서드를 생성한다.
• @Setter: 모든 필드의 setter 메서드를 생성한다.
  • 주의: 무분별한 setter 사용은 캡슐화 원칙을 위배할 수 있으므로 필요한 경우에만 사용해야 한다.
• @NoArgsConstructor: 기본 생성자를 생성한다.
• @AllArgsConstructor: 모든 필드 값을 파라미터로 받는 생성자를 생성한다.
  • 주의: 모든 필드에 대한 생성자를 만드는 것은 객체의 일관성을 해칠 수 있으므로 지양하는 것이 좋다.
• @ToString: 객체의 toString 메서드를 생성한다.
  • 주의: 양방향 연관관계에서 순환 참조 문제가 발생할 수 있으므로 연관관계의 필드를 제외하는 것이 좋다.
• @Data: @Getter, @Setter, @RequiredArgsConstructor, @ToString, @EqualsAndHashCode를 모두 포함한 종합 어노테이션.
  • 주의: @Data는 무분별하게 사용하면 캡슐화와 일관성을 해칠 수 있으므로 신중하게 사용해야 한다.

---

Section 03. TDD: Test Driven Development

1. TDD란?

• 정의: TDD(Test Driven Development)란 프로덕션 코드보다 테스트 코드를 먼저 작성하여 테스트가 구현 과정을 주도하는 방법론이다.
• 사이클: TDD는 RED -> GREEN -> REFACTOR 세 가지 사이클을 반복하는 일정한 리듬 속에서 진행된다.

---

2. TDD 사이클

1. RED: 프로덕션 코드가 없는 상황에서 실패하는 테스트 코드를 먼저 작성한다.
2. GREEN: 실패하는 테스트 코드를 통과하기 위해 프로덕션 코드에서 최소한의 코드를 작성한다.
3. REFACTOR: 프로덕션 코드를 좋은 코드로 개선한다.

---

3. TDD의 핵심 가치

• 피드백: 내가 작성한 코드, 프로덕션 코드에 대해 자주, 빠르게 피드백을 받을 수 있다.

---

4. 선 기능 구현, 후 테스트 작성의 문제점

• 테스트 자체의 누락 가능성
• 특정 테스트 케이스(해피 케이스)만 검증할 가능성
• 잘못된 구현을 다소 늦게 발견할 가능성

---

5. 선 테스트 작성, 후 기능 구현의 장점

• 복잡도가 낮은(유연하며 유지보수가 쉬운), 테스트 가능한 코드로 구현할 수 있다.
• 쉽게 발견하기 어려운 엣지(Edge) 케이스를 놓치지 않게 해준다.
• 구현에 대한 빠른 피드백을 받을 수 있다.
• 과감한 리팩토링이 가능해진다.

---

6. TDD의 효과

• TDD는 우리의 사고와 관점의 변화를 일으키는 도구이다.
• TDD 도입 전의 테스트는 단순히 구현부 검증을 위한 보조 수단이었지만, TDD 도입 후에는 구현부 코드와 테스트 코드가 상호 작용하여 견고한 프로덕션 코드를 작성할 수 있게 해준다.

---

7. 결론

• TDD는 클라이언트 관점에서의 피드백을 주는 Test Driven 방법론이다.
• TDD가 익숙하지 않다면 익숙해질 때까지 시도해보자.

---

Section 04. 테스트는 문서다

1. 테스트를 문서라고 한 이유

• 설명 역할: 프로덕션 기능을 설명하는 테스트 코드는 문서가 될 수 있다.
• 이해 보완: 다양한 테스트 케이스를 통해 프로덕션 코드를 이해하는 시각과 관점을 보완할 수 있다.
• 지식 공유: 어느 한 사람이 과거에 경험했던 고민의 결과물을 팀 차원으로 승격시켜서, 모두의 자산을 공유할 수 있다.
• 팀워크: 실무에서는 항상 팀으로 일하기 때문에 나 또는 다른 누군가가 작성한 문서가 팀 전체에 큰 도움을 줄 수 있다.

---

2. DisplayName을 섬세하게

• DisplayName 사용: Junit5의 @DisplayName 어노테이션을 활용하여 테스트에 대한 설명을 한글로 작성하면 어떤 테스트를 의미하는지 쉽게 알 수 있다.
• 테스트 이름 작성 방법:
  • “~테스트”라고 작성하는 것을 지양하고 문장으로 작성한다. 예: “음료를 1개 추가할 수 있다.”
  • 테스트 행위에 대한 결과까지 기술한다. 예: “음료를 1개 추가하면 주문 목록에 담긴다.”
  • 도메인 용어를 사용하여 한층 추상화된 내용을 담는다. 예: “영업 시작 이전에는 주문을 생성할 수 없다.”

---

3. BDD 스타일로 작성하기

• BDD(Behavior Driven Development): TDD에서 파생된 개발 방법으로 함수 단위의 테스트에 집중하기보다, 시나리오에 기반한 테스트케이스(TC) 자체에 집중하여 테스트를 한다.
• 추상화 수준: 개발자가 아닌 사람이 봐도 이해할 수 있을 정도의 추상화 수준을 권장한다.
• Given / When / Then:
  • Given: 시나리오 진행에 필요한 모든 준비 과정(객체, 값, 상태)
  • When: 시나리오 행동 진행
  • Then: 시나리오 진행에 대한 결과 명시, 검증(AssertJ)

---

4. BDD 스타일 예제

class CafeKioskTest {
    @DisplayName("주문 목록에 담긴 상품들의 총 금액을 계산할 수 있다.")
    @Test
    void calculateTotalPrice() {
        // given
        CafeKiosk cafeKiosk = new CafeKiosk();
        Americano americano = new Americano();
        Latte latte = new Latte();

        cafeKiosk.add(americano);
        cafeKiosk.add(latte);

        // when
        int totalPrice = cafeKiosk.calculateTotalPrice();

        // then
        assertThat(totalPrice).isEqualTo(8500);
    }
}

---

5. [Tip] IntelliJ Live Template 설정 방법

(1) 설정 경로: IntelliJ IDEA - Preferences - Live Templates - Java - test
(2) Template 설정: 아래와 같이 입력하고 Apply 후 Ok 버튼을 클릭한다.

@Test
void $TEST_NAME$() {
    // given

    // when

    // then
}

(3) 사용 방법: 다음부터 test를 입력하면 설정한 템플릿이 자동으로 입력된다.

---

Section 05. Spring & JPA 기반 테스트

1. 레이어드 아키텍처와 통합 테스트

1) 레이어드 아키텍처

• 구조: 사용자의 요청을 Presentation Layer, Business Layer, Persistence Layer로 구분하여 처리하는 구조.
• 목적: 관심사를 분리해 책임을 나누고 유지보수를 용이하게 만든다.
• 테스트 접근 방법: 관심사가 분리되어 있으므로 각 레이어별로 테스트를 독립적으로 접근할 수 있다.

 

2) 통합 테스트

• 정의: 여러 모듈이 협력하는 기능을 통합적으로 검증하는 테스트.
• 필요성: 단위 테스트만으로는 기능 전체의 신뢰성을 보장할 수 없다. 풍부한 단위 테스트와 통합 테스트를 병행해야 한다.

---

2. Spring / JPA & 기본 엔티티 설계

1) Spring Framework

• 라이브러리 vs 프레임워크: 라이브러리는 필요한 기능만 끌어와서 사용하는 반면, 프레임워크는 이미 갖춰진 환경 안에 코드를 끼워 넣어 동작하게 된다.
• Spring의 주요 개념:
  • IoC(Inversion of Control) : 객체의 제어 권한을 프레임워크가 관리하는 설계 원칙.
  • DI(Dependency Injection) : 객체 간의 의존성을 외부에서 주입하는 설계 패턴.
  • AOP (Aspect Oriented Programming) : 핵심 비즈니스 로직과 횡단 관심사를 분리하여 모듈화하는 프로그래밍 기법.

2) ORM과 JPA

• ORM: 객체와 관계형 데이터베이스의 데이터를 자동으로 매핑.
• JPA: 자바에서 사용되는 ORM의 표준. 구현체로는 Hibernate 등이 있다.
• Spring Data JPA: JPA를 추상화하여 사용하기 쉽게 만든 스프링 진영의 라이브러리.

 

3) Entity 설계

• Order(주문)와 Product(상품) 엔티티 설계.
• 다대다 관계를 일대다, 다대일 관계로 풀어서 접근하기 위해 중간 매핑 테이블(OrderProduct)을 사용.

@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Table(name = "orders")
@Entity
public class Order extends BaseEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Enumerated(EnumType.STRING)
    private OrderStatus orderStatus;

    private int totalPrice;

    private LocalDateTime registeredDateTime;

    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL)
    private List<OrderProduct> orderProducts = new ArrayList<>();

    public Order(List<Product> products, LocalDateTime registeredDateTime) {
        this.orderStatus = OrderStatus.INIT;
        this.totalPrice = calculateTotalPrice(products);
        this.registeredDateTime = registeredDateTime;
        this.orderProducts = products.stream()
                .map(product -> new OrderProduct(this, product))
                .collect(Collectors.toList());
    }
}

@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Entity
public class OrderProduct extends BaseEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @ManyToOne(fetch = FetchType.LAZY)
    private Order order;

    @ManyToOne(fetch = FetchType.LAZY)
    private Product product;

    public OrderProduct(Order order, Product product) {
        this.order = order;
        this.product = product;
    }
}

---

3. Persistence Layer

• 역할: Data Access의 역할로, 비즈니스 로직이 포함되지 않으며, CRUD 작업에만 집중한다.
• ProductRepository 클래스:

@Repository
public interface ProductRepository extends JpaRepository<Product, Long> {

    /**
     * select *
     * from product
     * where selling_type in ('SELLING', 'HOLD')
     */
    List<Product> findAllBySellingStatusIn(List<ProductSellingStatus> sellingStatuses);
}

 

1) Repository 테스트

• 단위 테스트: Data Access하는 로직만 포함되어 단위 테스트의 성격을 가진다.
• 테스트 예제:

@ActiveProfiles("test")
@DataJpaTest
class ProductRepositoryTest {

    @Autowired
    private ProductRepository productRepository;

    @DisplayName("원하는 판매상태를 가진 상품들을 조회한다.")
    @Test
    void findAllBySellingStatusIn() {
        // given
        Product product1 = createProduct("001", HANDMADE, SELLING, "아메리카노", 4000);
        Product product2 = createProduct("002", HANDMADE, HOLD, "카페라떼", 4500);
        Product product3 = createProduct("003", HANDMADE, STOP_SELLING, "팥빙수", 7000);
        productRepository.saveAll(List.of(product1, product2, product3));

        // when
        List<Product> products = productRepository.findAllBySellingStatusIn(List.of(SELLING, HOLD));

        // then
        assertThat(products).hasSize(2)
                .extracting("productNumber", "name", "sellingStatus")
                .containsExactlyInAnyOrder(
                        tuple("001", "아메리카노", SELLING),
                        tuple("002", "카페라떼", HOLD)
                );
    }

    private Product createProduct(String productNumber, ProductType type, ProductSellingStatus sellingStatus, String name, int price) {
        return Product.builder()
                .productNumber(productNumber)
                .type(type)
                .sellingStatus(sellingStatus)
                .name(name)
                .price(price)
                .build();
    }
}

---

4. Business Layer

• 역할: 비즈니스 로직을 구현하고, Persistence Layer와 상호작용을 통해 비즈니스 로직을 전개한다.
• 트랜잭션 보장: 비즈니스 로직 수행 시 트랜잭션을 보장해야 한다.

 

1) OrderService 테스트

• 예제:

@ActiveProfiles("test")
@SpringBootTest
class OrderServiceTest {

    @Autowired
    private ProductRepository productRepository;
    @Autowired
    private OrderRepository orderRepository;
    @Autowired
    private OrderProductRepository orderProductRepository;
    @Autowired
    private StockRepository stockRepository;
    @Autowired
    private OrderService orderService;

    @AfterEach
    void tearDown() {
        orderProductRepository.deleteAllInBatch();
        productRepository.deleteAllInBatch();
        orderRepository.deleteAllInBatch();
        stockRepository.deleteAllInBatch();
    }

    @DisplayName("주문번호 리스트를 받아 주문을 생성한다.")
    @Test
    void createOrder() {
        LocalDateTime registeredDateTime = LocalDateTime.now();
        // given
        Product product1 = createProduct(HANDMADE, "001", 1000);
        Product product2 = createProduct(HANDMADE, "002", 3000);
        Product product3 = createProduct(HANDMADE, "003", 5000);
        productRepository.saveAll(List.of(product1, product2, product3));

        OrderCreateServiceRequest request = OrderCreateServiceRequest.builder()
                .productNumbers(List.of("001", "002"))
                .build();
        // when
        OrderResponse orderResponse = orderService.createOrder(request, registeredDateTime);

        // then
        assertThat(orderResponse.getId()).isNotNull();
        assertThat(orderResponse)
                .extracting("registeredDateTime", "totalPrice")
                .contains(registeredDateTime, 4000);
        assertThat(orderResponse.getProducts()).hasSize(2)
                .extracting("productNumber", "price")
                .containsExactlyInAnyOrder(
                        tuple("001", 1000),
                        tuple("002", 3000)
                );
    }

    @DisplayName("중복되는 상품번호 리스트로 주문을 생성할 수 있다.")
    @Test
    void createOrderWithDuplicateProductNumbers() {
        // given
        LocalDateTime registeredDateTime = LocalDateTime.now();
        Product product1 = createProduct(HANDMADE, "001", 1000);
        Product product2 = createProduct(HANDMADE, "002", 3000);
        Product product3 = createProduct(HANDMADE, "003", 5000);
        productRepository.saveAll(List.of(product1, product2, product3));

        OrderCreateServiceRequest request = OrderCreateServiceRequest.builder()
                .productNumbers(List.of("001", "001"))
                .build();
        // when
        OrderResponse orderResponse = orderService.createOrder(request, registeredDateTime);

        // then
        assertThat(orderResponse.getId()).isNotNull();
        assertThat(orderResponse)
                .extracting("registeredDateTime", "totalPrice")
                .contains(registeredDateTime, 2000);
        assertThat(orderResponse.getProducts()).hasSize(2)
                .extracting("productNumber", "price")
                .containsExactlyInAnyOrder(
                        tuple("001", 1000),
                        tuple("001", 1000)
                );
    }
}

• 테스트 클래스와 @Transactional:
  • OrderServiceTest에서 @Transactional을 제거하고 @AfterEach를 사용하는 이유:
    • @Transactional을 사용하면 update 쿼리가 나가지 않아 테스트가 실패할 수 있다.
    • @AfterEach를 통해 수동으로 데이터를 삭제하여 테스트 간의 데이터 영향을 최소화한다.

---

4. API 테스트

• 설정:
  • 최상단에 http 폴더를 만들고 그 안에 order.http, product.http 파일을 생성한다.
  • 예제:

POST localhost:8080/api/v1/orders/new
Content-Type: application/json

{
  "productNumbers": [
    "001",
    "002"
  ]
}

GET localhost:8080/api/v1/products/selling

---

5. Presentation Layer

• 역할: 외부 세계의 요청을 가장 먼저 받는 계층으로, 파라미터에 대한 최소한의 검증을 수행한다.
• 목적: 비즈니스 로직보다는 넘겨온 값이 유효한지 검증하는 것이 최우선이다.
• Mocking: 하위 2개의 Layer를 Mocking(가짜 객체로 대체)하고 Presentation Layer를 테스트한다.

 

1) Mock 사용 이유

• 의존관계 차단: 하나의 객체 또는 하나의 레이어를 테스트할 때, 의존관계가 있는 것들이 방해가 된다. 이를 가짜 객체로 대체해 처리하고자 한다.
• MockMvc: Mock 객체를 사용해 스프링 MVC 동작을 재현할 수 있는 테스트 프레임워크.

 

2) 요구사항: 관리자 페이지에서 신규 상품을 등록

• 상품명, 상품 타입, 판매 상태, 가격 등을 입력받는다.

 

3) ProductService 예제

• 동시성 문제 해결: 상품번호 필드에 유니크 제약 조건을 걸고 재시도 로직을 추가하거나 UUID를 사용하여 해결할 수 있다.
• Transactional 설정: @Transactional(readOnly = true)를 사용해 성능 향상을 도모하고, CQRS 원칙을 적용해 Command와 Query를 분리한다.

@Transactional(readOnly = true)
@RequiredArgsConstructor
@Service
public class ProductService {

    private final ProductRepository productRepository;

    // 동시성 이슈 해결을 위한 재시도 로직 추가
    @Transactional
    public ProductResponse createProduct(ProductCreateServiceRequest request) {
        String nextProductNumber = createNextProductNumber();

        Product product = request.toEntity(nextProductNumber);
        Product savedProduct = productRepository.save(product);

        return ProductResponse.of(savedProduct);
    }

    @Transactional
    private String createNextProductNumber() {
        String latestProductNumber = productRepository.findLatestProductNumber();
        if (latestProductNumber == null) {
            return "001";
        }
        int latestProductNumberInt = Integer.parseInt(latestProductNumber);
        int nextProductNumberInt = latestProductNumberInt + 1;

        return String.format("%03d", nextProductNumberInt);
    }

    public List<ProductResponse> getSellingProducts() {
        List<Product> products = productRepository.findAllBySellingStatusIn(ProductSellingStatus.forDisplay());
        return products.stream()
                .map(ProductResponse::of)
                .collect(Collectors.toList());
    }
}

 

4) ControllerTest - @WebMvcTest

• 사용 방법: @WebMvcTest 어노테이션을 사용해 컨트롤러 관련 테스트를 진행하고, MockMvc를 활용해 Mocking 처리.

@WebMvcTest(controllers = ProductController.class)
class ProductControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @Autowired
    private ObjectMapper objectMapper;

    @MockBean
    private ProductService productService;

    @DisplayName("신규 상품을 등록한다.")
    @Test
    void createProduct() throws Exception {
        // given
        ProductCreateRequest request = ProductCreateRequest.builder()
                .type(ProductType.HANDMADE)
                .sellingStatus(ProductSellingStatus.SELLING)
                .name("아메리카노")
                .price(4000)
                .build();

        // when & then
        mockMvc.perform(post("/api/v1/products/new")
                    .content(objectMapper.writeValueAsString(request))
                    .contentType(MediaType.APPLICATION_JSON)
                )
                .andDo(print()) // log 확인
                .andExpect(status().isOk());
    }
}

@RequiredArgsConstructor
@RestController
public class ProductController {

    private final ProductService productService;

    @PostMapping("/api/v1/products/new")
    public ProductResponse createProduct(@RequestBody ProductCreateRequest request) {
        return productService.createProduct(request);
    }
}

 

5) Controller에서 유효성 검사

• 의존성 추가: 스프링 빈 유효성 검사를 위해 의존성을 추가한다.
• DTO에 유효성 어노테이션 추가: @NotNull, @NotBlank, @Positive 등.

@Getter
@NoArgsConstructor
public class ProductCreateRequest {

    @NotNull
    private ProductType type;

    @NotNull
    private ProductSellingStatus sellingStatus;

    @NotBlank
    private String name;

    @Positive
    private int price;
}

@RequiredArgsConstructor
@RestController
public class ProductController {

    private final ProductService productService;

    @PostMapping("/api/v1/products/new")
    public ProductResponse createProduct(@Valid @RequestBody ProductCreateRequest request) {
        return productService.createProduct(request);
    }
}

---

6) DTO를 통한 계층적 구조에서 의존성 관계

• 목적: 하위 계층인 Service가 상위 계층인 Controller를 모르게 구현하여, 책임 분리를 명확히 한다.
• 방법: Controller의 DTO와 Service의 DTO를 분리한다.

@RequiredArgsConstructor
@RestController
public class OrderController {

    private final OrderService orderService;

    @PostMapping("/api/v1/orders/new")
    public ApiResponse<OrderResponse> createOrder(@Valid @RequestBody OrderCreateRequest request) {
        LocalDateTime registeredDateTime = LocalDateTime.now();
        return ApiResponse.ok(orderService.createOrder(request.toServiceRequest(), registeredDateTime));
    }
}

@Getter
@NoArgsConstructor
public class OrderCreateRequest {

    @NotEmpty(message = "상품 번호 리스트는 필수입니다.")
    private List<String> productNumbers;

    @Builder
    public OrderCreateRequest(List<String> productNumbers) {
        this.productNumbers = productNumbers;
    }

    public OrderCreateServiceRequest toServiceRequest() {
        return OrderCreateServiceRequest.builder()
                .productNumbers(productNumbers)
                .build();
    }
}

@Getter
@NoArgsConstructor
public class OrderCreateServiceRequest {
    private List<String> productNumbers;

    @Builder
    public OrderCreateServiceRequest(List<String> productNumbers) {
        this.productNumbers = productNumbers;
    }
}

---

7) Spring & JPA 기반 테스트 리뷰

• 계층별 테스트 작성:
  • Presentation Layer(Controller): Business Layer, Persistence Layer를 Mocking 처리하여 단위 테스트.
  • Business Layer(Service): Persistence Layer를 주입받아 통합 테스트. @SpringBootTest를 사용하고, 수동 삭제 메서드(tearDown) 활용.
  • Persistence Layer(Repository): Data Access 로직만을 테스트하는 단위 테스트. @DataJpaTest 사용.
• DTO 구분: 각 Layer마다 DTO를 구분해 의존성과 책임 분리.
• 유효성 검사: Presentation Layer에서 기본적인 유효성 검사, 도메인 유효성 검증은 도메인 객체에서 처리.

---

8) 결론

• Mocking: Mocking을 통해 의존관계를 차단하고 단위 테스트를 효율적으로 수행.
• 유효성 검사: Controller에서 기본적인 유효성 검사를 수행하고, 도메인 유효성 검증은 도메인 객체에서 처리.
• DTO 분리: 각 Layer마다 DTO를 구분해 의존성과 책임을 분리.
• 계층별 테스트: 각 계층에 맞는 테스트 전략을 적용해 통합 테스트와 단위 테스트를 병행.