요구사항

• 주문 목록에 음료 추가/삭제 기능
• 주문 목록 전체 지우기
• 주문 목록 총 금액 계산하기
• 주문 생성하기
• 한 종류의 음료 여러 잔을 한 번에 담는 기능
• 가게 운영 시간(10:00 ~ 22:00) 외에는 주문을 생성할 수 없다.
• 키오스크 주문을 위한 상품 후보 리스트 조회하기
• 상품의 판매 상태: 판매중, 판매보류, 판매중지
  • 판매중, 판매보류인 상태의 상품을 화면에 보여준다.
• ID, 상품번호, 상품타입, 판매상태, 상품이름, 가격
• 상품 번호 리스트를 받아 주문 생성하기
• 주문은 주문 상태, 주문 등록 시간을 가진다.
• 주문의 총 금액을 계산할 수 있어야 한다.
• 주문 생성 시 재고 확인 및 개수 차감 후 생성하기
• 재고는 상품번호를 가진다.
• 재고와 관련 있는 상품 타입은 병 음료, 베이커리이다.
• 관리자 페이지에서 신규 상품을 등록할 수 있다.
• 상품명, 상품 타입, 판매 상태, 가격 등을 입력받는다.

---

단위 테스트

• 작은 코드 단위(클래스 or 메서드)를 독립적으로 검증하는 테스트
• 검증 속도가 빠르고, 안정적이다.

테스트 케이스 세분화하기

• 해피케이스
• 예외케이스
  • 경계값 테스트 (범위(이상, 이하, 초과, 미만), 구간, 날짜 등)

테스트하기 어려운 영역을 구분하고 분리하기

외부로 분리할수록 테스트 가능한 코드는 많아진다.

테스트하기 어려운 영역

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

테스트 하기 쉬운 함수(순수함수)

1. 같은 입력에는 항상 같은 결과
2. 외부 세상과 단절된 형태
3. 테스트하기 쉬운 코드

---

TDD(Test Driven Development)

프로덕션 코드보다 테스트 코드를 먼저 작성하여 테스트가 구현 과정을 주도하도록 하는 방법론

RED → GREEN → REFACTOR

RED: 실패하는 테스트 작성
GREEN: 테스트 통과 / 최소한의 코딩
REFACTOR: 구현 코드 개선 / 테스트 통과 유지

선 기능 구현, 후 테스트 작성

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

선 테스트 작성, 후 기능 구현

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

TDD: 관점의 변화
테스트는 구현부 검증을 위한 보조수단 → 테스트와 상호 작용하며 발전하는 구현부

클라이언트 관점에서 피드백을 주는 Test Driven

---

테스트는 문서다

• 프로덕션 기능을 설명하는 테스트 코드 문서
• 다양한 테스트케이스를 통해 프로덕션 코드를 이해하는 시각과 관점을 보완
• 어느 한 사람이 과거에 경험했던 고민의 결과물을 팀 차원으로 승격시켜서, 모두의 자산으로 공유할 수 있다.

DisplayName은 섬세하게

• 명사의 나열보다 문장으로
  • 음료 1개 추가 테스트 → 음료를 1개 추가할 수 있다.
• 테스트 행위에 대한 결과까지 기술하기
  • 음료를 1개 추가할 수 있다. → 음료를 1개 추가하면 주문 목록에 담긴다.
• 도메인 용어를 사용하여 한층 추상화된 내용을 담기(메서드 자체의 관점보다 도메인 정책 관점으로)
  • 특정 시간 이전에 주문을 생성하면 실패한다 → 영업 시작 시간 이전에는 주문을 생성할 수 없다.
• 테스트의 현상을 중점으로 기술하지 말 것
  • 성공한다/실패한다 → 담긴다/생성할 수 없다

BDD: Behavior Driven Development

• TDD에서 파생된 개발 방법
• 함수 단위의 테스트에 집중하기보다, 시나리오에 기반한 테스트케이스 자체에 집중하여 테스트한다.
• 개발자가 아닌 사람이 봐도 이해할 수 있을 정도의 추상화 수준(레벨)을 권장

Given/When/Then

• Given: 시나리오 진행에 필요한 모든 준비 과정 (객체, 값, 상태 등)
• When: 시나리오 행동 진행
• Then: 시나리오 진행에 대한 결과 명시, 검증

---

Spring & JPA 기반 테스트

레이어드 아키텍처(Layered Architecture)

• Persistence Layer
  • Data Access 역할
  • 비지니스 가공 로직이 포함되어서는 안 된다.
  • Data에 대한 CRUD에만 집중한 레이어
• Business Layer
  • 비즈니스 로직을 구현하는 역할
  • Persistence Layer와 상호작용(Data를 읽고 쓰는 행위)을 통해 비즈니스 로직을 전개시킨다.
  • 트랜잭션을 보장해야 한다.
• Presentation Layer
  • 외부 세계의 요청을 가장 먼저 받는 계층
  • 파라미터에 대한 최소한의 검증을 수행한다.

통합테스트

• 여러 모듈이 협락하는 기능을 통합적으로 검증하는 테스트
• 일반적으로 작은 범위의 단위테스트만으로는 기능 전체의 신뢰성을 보장할 수 없다.
• 풍부한 단위테스트 & 큰 기능 단위를 검증하는 통합테스트

MockMvc

• Mock(가짜) 객체를 사용해 스프링 MVC 동작을 재현할 수 있는 테스트 프레임워크

Keyword

• Layerd Architecture
• Hexagonal Architecture
• 단위테스트 vs 통합테스트
• IoC, DI, AOP
• ORM, 패러다임의 불일치, Hibernate
• Spring Data JPA
• QueryDSL
• @SpringBootTest vs @DataJpaTest
• @SpringBootTest vs @WebMvcTest
• Optimistic Lock, Pessimistic Lock
• CQRS
• @RestControllerAdvice, @ExceptionHandler
• Spring Bean Validation
  • @NotNull, @NotEmpty, @NotBlank, ...
• Mock, Mockito, @MockBean