단위 테스트 코드 작성 방법

단위 테스트란?

단위 테스트(Unit Test)는
하나의 모듈을 기준으로 독립적으로 수행되는 가장 작은 단위의 테스트이다.

여기서 말하는 모듈이란,
애플리케이션에서 동작하는 하나의 기능 또는 하나의 메서드를 의미한다.

---

단위 테스트의 어려움

일반적인 애플리케이션에서는
하나의 기능을 처리하기 위해 여러 객체와 메시지를 주고받는다.

하지만 단위 테스트는 특정 모듈을 독립적으로 검증하는 것이 목적이기 때문에,
다른 객체와의 협력이 포함되면 테스트가 어려워진다.

이 문제를 해결하기 위해,
단위 테스트에서는 실제 객체 대신 가짜 객체(Mock Object)를 주입하고
“어떤 상황에서 어떤 결과를 반환할지”를 미리 정의한다.

이렇게 미리 정해진 응답을 준비하는 과정을 Stub이라고 한다.

---

좋은 단위 테스트의 특징

좋은 단위 테스트는 다음 원칙을 따른다.

• 하나의 테스트 함수는 하나의 개념만 검증한다

• 테스트 함수 내에서 assert는 최소화한다

또한, 좋은 테스트 코드는 흔히 FIRST 원칙을 만족해야 한다.

• Fast
  테스트는 빠르게 실행되어 자주 돌릴 수 있어야 한다.

• Independent
  각 테스트는 서로 의존하지 않고 독립적으로 실행되어야 한다.

• Repeatable
  어떤 환경에서도 동일한 결과를 보장해야 한다.

• Self-Validating
  성공 또는 실패가 명확해야 하며, 추가 해석이 필요 없어야 한다.

• Timely
  실제 코드를 작성하기 직전 또는 동시에 작성되어야 한다.

---

Given / When / Then 패턴

단위 테스트에서는
테스트의 의도를 코드만 보고도 이해할 수 있도록 만드는 것이 중요하다.

이를 위해 가장 널리 사용되는 구조가
Given / When / Then 패턴이다.

• Given: 테스트를 위한 사전 조건을 준비한다.

• When: 테스트 대상의 동작을 실행한다.

• Then: 실행 결과를 검증한다.

이 패턴의 목적은

“이 테스트가 무엇을 검증하는지”
를 코드 구조만으로 드러내는 데 있다.

---

외부 의존성이 없는 경우: 순수 객체 기반 테스트

로또 번호 생성기 예제처럼
외부 의존성이 전혀 없는 경우에는 매우 단순한 테스트 구조를 유지할 수 있다.

// given
final LottoNumberGenerator lottoNumberGenerator = new LottoNumberGenerator();
final int price = 1000;

// when
final List<Integer> lotto = lottoNumberGenerator.generate(price);

// then
assertThat(lotto).hasSize(6);

이 경우 테스트 대상은 오직 하나의 객체이며,
new 키워드만으로 충분히 단위 테스트를 구성할 수 있다.

---

왜 예약 도메인에서는 같은 방식이 어려울까?

예약 도메인의 서비스 로직은
로또 예제와 구조적으로 다르다.

하나의 기능을 수행하기 위해
여러 협력 객체와 메시지를 주고받기 때문이다.

photoLabRepository.findById(...)
memberUserRepository.findById(...)
reservationSlotRepository.findByPhotoLabIdAndReservationDateAndReservationTimeForUpdate(...)
reservationRepository.save(...)

이 서비스는 다음과 같은 특징을 가진다.

• Repository를 통해 DB에 접근한다.

• 트랜잭션과 락 조회가 포함된다.

• 여러 협력 객체의 상태에 따라 분기 로직이 달라진다.

이런 구조에서는 단순히 객체를 new 해서 테스트를 실행할 수 없다.
테스트가 DB 상태, 트랜잭션 환경, 외부 설정에 영향을 받게 되기 때문이다.

즉, Mock 없이 실제 협력 객체만으로는
순수 객체 기반 단위 테스트를 구성하기 어렵다.

---

그래서 단위 테스트에서는 Mock을 사용한다

이러한 문제를 해결하기 위해,
단위 테스트에서는 실제 객체 대신 행동이 고정된 가짜 객체(Mock)를 주입한다.

중요한 점은,
Mock을 사용하더라도 테스트의 초점은 여전히 Service에 있다는 것이다.

---

Mock을 사용했지만, 테스트의 초점은 Service에 있다

아래 테스트는
ReservationCommandService 하나의 개념만을 검증한다.

@ExtendWith(MockitoExtension.class)
class ReservationCommandServiceImplTest {

    @Mock PhotoLabRepository photoLabRepository;
    @Mock MemberUserRepository memberUserRepository;
    @Mock ReservationRepository reservationRepository;
    @Mock ReservationSlotRepository reservationSlotRepository;

    @InjectMocks
    ReservationCommandServiceImpl service;
}

모든 Repository는 Mock으로 대체되었고,
각각의 반환 값은 Given 단계에서 명확하게 정의된다.

given(photoLabRepository.findById(labId))
        .willReturn(Optional.of(lab));

given(memberUserRepository.findById(memberId))
        .willReturn(Optional.of(user));

이를 통해 이 테스트는

• DB 동작을 검증하지 않고

• 트랜잭션 구현을 신경 쓰지 않으며

• 오직
  **“이 서비스가 주어진 상황에서 올바른 결정을 내리는지”**만 확인한다.

---

Given 지옥을 피하기 위해 적용한 방법

협력 객체가 많은 서비스 테스트에서는
Given 코드가 길어지기 쉽다.

이를 방치하면 테스트의 의도가 흐려진다.

1. Fixture로 객체 생성 책임을 분리했다

var lab = ReservationDomainFixture.photoLab(labId);
var user = ReservationDomainFixture.memberUser(memberId);
var slot = ReservationDomainFixture.slot(lab, 100L, date, time);

테스트에서는
무엇을 검증하는지만 드러나야 한다.

객체 생성 방식은 Fixture로 숨긴다.

---

2. 결과 중심으로 검증했다

assertThat(response.reservationId()).isEqualTo(777L);

내부 구현이 아니라
최종 결과와 핵심 부작용만 검증한다.

---

3. 한 테스트는 하나의 개념만 검증했다

void createReservation_정상_슬롯없으면_생성후_예약저장()

• 메서드 이름 자체가 시나리오

• 실패 원인이 즉시 드러남

• 불필요한 assert 제거

---

Spring Context를 띄우지 않은 이유

이 테스트는 @SpringBootTest를 사용하지 않는다.
즉, Spring Application Context를 띄우지 않는다.

그 결과 다음과 같은 장점이 있다.

• 테스트 실행 속도가 빠르다 (Fast)

• 테스트 간 상태 공유가 없다 (Independent)

• 환경에 관계없이 반복 가능하다 (Repeatable)

이는 FIRST 원칙을 충족하는
단위 테스트에 가까운 구조이다.

---

정리

• 단위 테스트는 “Mock이 없는 테스트”가 아니다.

• 단위 테스트의 핵심은
  하나의 개념을 외부 영향 없이 검증하는 것이다.

• 외부 환경에 의해 결과가 달라질 수 있는 의존성만 Mock으로 대체한다.

• Given / When / Then 구조를 통해 테스트의 의도를 드러낸다.

• Fixture와 명확한 네이밍으로 Given 지옥을 줄인다.

이러한 기준을 지키면,
협력 객체가 많은 서비스 로직에서도
읽기 쉽고 신뢰할 수 있는 단위 테스트를 작성할 수 있다.