더 나은 테스트를 작성하기 위한 구체적 조언 + 나의 생각

테스트 환경의 독립성을 보장하자

아래와 같은 테스트 코드가 있다고 생각하자.

@DisplayName("재고가 부족한 상품으로 주문을 생성하려는 경우 예외가 발생한다.")
@Test
void createOrderWithNoStock() {
    // given
    LocalDateTime registeredDateTime = LocalDateTime.now();

    Product product1 = createProduct(BOTTLE, "001", 1000);
    Product product2 = createProduct(BAKERY, "002", 3000);
    Product product3 = createProduct(HANDMADE, "003", 5000);
    productRepository.saveAll(List.of(product1, product2, product3);

    Stock stock1 = Stock.create("001", 2);
    Stock stock2 = Stock.create("002", 2);
    stock1.deductQuantity(1); // 수량을 감소시키는 메서드
    stockRepository.saveAll(List.of(stock1, stock2));

    OrderCreateServiceRequest request = OrderCreateServiceRequest.builder()
        .productNumbers(List.of("001", "001", "002", "003")
        .build();

    // when // then
    assertThatThrownBy(() -> orderService.createOrder(reqeust, requestDateTime))
        .isInstanceOf(IllegalArgumentException.class)
        .hasMessage("재고가 부족한 상품이 있습니다.");

}

 

위 테스트 코드에서 확인하고 싶은 것은 재고가 부족한 상품으로 주문을 생성할 때 올바른 예외가 발생하는지이다.

 

stock1.deductQuantity(1); // 수량을 감소시키는 메서드

 

문제는 위 메서드인데,

위 메서드를 사용함으로써 테스트 환경의 독립성을 보장할 수 없게 된 것이다.

 

현재 테스트 코드에서 `stock1`의 재고 수량은 2이다.

 

이때 `stock1.deductQuantity(1);`이 아니라 `stock1.deductQuantity(3);`을 한다면,  재고 수량이 부족하여 "차감할 재고 수량이 없습니다."라는 예외 메시지로 테스트가 실패한다.

 

즉, 재고 차감 메서드로 인해 주문 생성 시 재고 부족 테스트 환경의 독립성이 보장되지 않은 것이다.

 

한 눈에 들어오는 Test Fixture 구성하기

✅ Fixture: 고정물, 고정되어 있는 물체

 

Test Fixture란 테스트를 위해 원하는 상태로 고정시킨 객체로, given 절을 구성할 때 주로 만나게 된다. 테스트가 시작되기 전에 필요한 초기 상태를 설정하거나 필요한 데이터 또는 객체를 준비하는 역할을 한다.

 

결론부터 말하자면, Test Fixture를 파편화하는 것은 "문서"로서의 테스트를 구성할 때 이해하기 어렵게 만든다.

 

테스트는 단순히 코드의 동작을 검증하는 것을 넘어, 테스트의 의도를 문서처럼 명확히 드러내야 한다. 테스트를 읽는 사람이 given절만 보고도 "이 테스트가 어떤 상황을 설정하고자 하는지"를 쉽게 이해할 수 있어야 한다. 

 

따라서 given절이 길어지더라도 테스트가 단독으로 동작하도록 구성하는 것이 바람직하다.

 

일례로, 몇 년 전 사이드 프로젝트를 진행할 때에는 아래처럼 Test Fixture를 별도의 클래스로 분리하기도 했었다.

@Getter
@AllArgsConstructor
@RequiredArgsConstructor
public enum PetInfoFixture {

	VALID_PET("체리", 10, FOX, MALE, "hello! I'm 10 years Old, Wild fox!");

	private String name;
	private Integer age;
	private PetType type;
	private String bio;

	public PetInfo toEntity() {
		return PetInfo.builder()
			.name(name)
			.age(age)
			.type(type)
			.bio(bio)
			.build();
	}

	public PetProfileCreateRequest toRequest() {
		return PetProfileCreateRequest.builder()
			.name(name)
			.age(age)
			.type(type.toString())
			.bio(bio)
			.build();
	}
}

이 당시에는 테스트 코드에 대해 잘 모르는 상태였기 때문에 Test Fixture를 따로 분리하는 것이 깔끔해 보였고, 역할과 책임을 명확히 하는 것이라 생각했었다. 하지만 지금 생각해보면, 이런 방식은 지나치게 일반화되어 각 테스트의 맥락을 명확히 드러내는 데 소홀했던 방법이었다고 생각된다.