TIL

섹션 4. 테스트

PaymentService 테스트

Junit5를 통해 우리가 만든 코드의 자동화 테스트를 작성할 수 있다.

@Test
void prepare() throws IOException {
  PaymentService paymentService = 
      new PaymentService(new WebApiExRateProvider());
  
  Payment payment = paymentService.prepare(1L, "USD", BigDecimal.TEN);
  
  // 환율 정보 가져오기
  assertThat(payment.getExRate()).isNotNull();
  
  // 원화 환산 금액 계산
  assertThat(payment.getConvertedAmount())
    .isEqualTo(paymentExRate().multiply(payment.getForeignCurrencyAmount()));
    
  // 원화 환산 금액의 유효 계산 시간
  assertThat(payment.getValidUntil()).isAfter(LocalDateTime.now());
  assertThat(payment.getValidUntil()).isBefore(LocalDateTime.now().plusMinutes(30));
}

테스트 구성 요소

위 PaymentServiceTest에는 문제가 있다.
- 우리가 제어할 수 없는 외부 시스템(open api)에 문제가 생기면?
- ExRateProvider가 제공하는 환율 값으로 계산한 것인가?
- 환율 유효 시간 계산은 정확한가?

SUT

System Unter Test의 약자로 테스트 대상을 의미한다.
SUT는 보통 홀로 동작하지 않고 협력자(의존 오브젝트)와 상호작용하여 동작한다.
PaymentService가 SUT라면 WebApiExRateProvider는 협력자다.
- PaymentServiceTest에서 WebApiExRateProvider는 우리가 테스트 하고 싶어하는 대상인가?
- 협력자이기 때문에 안 쓸 순 없는데 제어할 수 없는 외부 시스템이기 때문에 번거롭다.
Stub을 사용해서 이 문제를 해결할 수 있다.
- 테스트용 오브젝트로 테스트에 필요한 협력자로서의 최소 동작만을 가진다.
- 이러한 대역을 Test Double이라고 부른다.

테스트와 DI

테스트 더블을 어떻게 사용할 수 있을까?
- ExRateProvider는 인터페이스이기 때문에 테스트에서만 구현체를 변경하는 기법을 사용할 수 있다.

public class ExRateProviderStub implements ExRateProvider {
  private BigDecinal exRate; // 미리 정해둔 값을 리턴하도록
  
  public ExRateProviderStub(BigDecimal exRate) {
    this.exRate = exRate;
  }
  
  @Override
  public BigDecimal getExRate(String currency) throw IOException {
    return exRate;
  }
}

@Test
void prepare() throws IOException {
  PaymentService paymentService = 
      new PaymentService(new ExRateProviderStub(BigDecimal.valueOf(500)));
  
  Payment payment = paymentService.prepare(1L, "USD", BigDecimal.TEN);
  
  // 환율 정보 가져오기
  assertThat(payment.getExRate()).isEqualTo(BigDecimal.valueOf(500));;
  
  // 원화 환산 금액 계산
  assertThat(payment.getConvertedAmount())
    .isEqualTo(BigDecimal.valueOf(5000));
    
  // 원화 환산 금액의 유효 계산 시간
  assertThat(payment.getValidUntil()).isAfter(LocalDateTime.now());
  assertThat(payment.getValidUntil()).isBefore(LocalDateTime.now().plusMinutes(30));
}

BigDecimal과 isEqualTo 주의
- BigDecimal은 숫자 뿐 아니라 유효 자리수도 따진다.
- isEqualTo는 내부적윽로 equals 메서드를 사용하는데 BigDecimal의 경우 유효 자리수가 다르면 실제로 값이 같더라도 서로 다른 값이라고 판단해버린다.
  - ex) 소수점 둘째자리까지 유효한 값과 6째자리까지 유효한 값이 같지 않다고 판단해 버린다. (1.34 vs 1.345241)
isEqualByComparingTo를 사용하면 된다.
- 내부적으로 isComapreTo를 사용

스프링 DI를 이용하는 테스트

위에서 작성한 테스트 코드는 수동으로 DI를 한 테스트였다.
스프링 DI를 이용하면 협력 관계를 직접 작성하지 않아도 된다.
- 테스트 협력자/의존 오브젝트를 스프링 구성 정보를 이용해 지정
- 컨테이너로부터 테스트 대상을 가져와 테스트
우선 테스트에서 사용할 ObjectFactory를 구현해보자

@Configuration
public class TestObjectFactory {
  @Bean
  public PaymentService paymentService() { return new PaymentService(exRateProvider()); }
  
  @Bean
  public ExRateProvider exRateProvider() { return new ExRateProviderStub(BigDecimal.valueOf(1_1000)); }
}

@ContextConfiguration 어노테이션으로 스프링 구성 정보에 빈을 추가할 수 있고 이를 @Autowired로 받아올 수 있다.

@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = TestObjectFactory.class)
class PaymentServiceSpringTest {
  @Autowired
  private PaymentService paymentService;

  @Test
  void prepare() throws IOException {
    Payment payment = paymentService.prepare(1L, "USD", BigDecimal.TEN);
  
    // ...
  }
}

스프링 DI를 이용한 테스트
- PaymentService의 의존 관계가 변한다고 해도 테스트에서의 DI는 변하지 않아도 된다.
아주 간단한 경우라면 수동 DI를 통해 빠르게 테스트를 수행할 수도 있을 것이다.

학습 테스트

켄트 백의 테스트 주도 개발 책에서 소개된 테스트 방법
직접 만들지 않은 코드, 라이브러리, 레거시 시스템에 대한 테스트
목적 - 테스트 대상의 사용 방법을 익히고 동작 방식을 확인하는데 유용하다.

Clock

아직 ‘환율 유효 시간 계산은 정확한가?’에 대해 해결하지 못했다.
Java의 Clock을 사용해서 테스트가 가능하도록 만들어볼 수 있다.
- 테스트에서 조작된 시간을 반환하도록 만들 수 있다.
- PaymentService가 Clock을 빈 주입 받도록 설계하면 된다.

Clock 학습 테스트 예제

학습 테스트를 프로젝트의 다른 테스트들과 함께 두는 것도 좋은 방법이다.
- 특정 기술에 대한 학습 테스트가 만들어져 있다면 그 기술이 생소한 다른 팀원들이 학습 테스트를 참고하고 공부할 수도 있다.

- test
  - java
    - tobyspring.hellospring
      - learningtest
        - ClockTest.java
      - payment

class ClockTest {
  @Test
  void clock을_이용해서_LocalDateTime을_호출() {
    Clock clock = Clock.systemDefaultZone();
    
    LocalDateTime dt1 = LocalDateTime.now(clock);
    LocalDateTime dt2 = LocalDateTime.now(clock);
    
    assertThat(dt2).isAfter(dt1);
  }
  
  @Test
  void clock을_사용해_원하는_시간을_지정할_수_있다() {
    Clock clock = Clock.fixed(Instant.now(), ZoneId.systemDefault());
    
    LocalDateTime dt1 = LocalDateTime.now(clock);
    LocalDateTime dt2 = LocalDateTime.now(clock);
    
    assertThat(dt2).isEqualTo(dt1);
  }
}

Clock을 이용한 시간 테스트

Clock을 스프링 빈으로 만든 뒤 PaymentService에서 주입 받을 필요가 있다.

// 보통 이렇게 스프링 구성 정보를 설정하는 책임을 가지는 클래스를 XXXConfig 혹은 XXXConfiguration이라 부른다.
// ObjectFactory -> PaymentConfig라고 이름을 변경
@Configuration
public class PaymentConfig {
  @Bean
  public PaymentService paymentService() {
    return new PaymentService(cachedExRateProvider(), clock());
  }
  
  // ...
  
  @Bean
  public Clock clock() { return Clock.systemDefaultZone(); }
}

public class PaymentService {
  private final ExRateProvider exRateProvider;
  private final Clock clock; // 의존성 주입
  
  public PaymentService(ExRateProvider exRateProvider, Clock clock) {
    this.exRateProvider = exRateProvider;
    this.clock = clock;
  }

  public Payment prepare(Long orderId, String currency, BigDecimal foreignCurrencyAmount) throws IOException {
    BigDecimal exRate = exRateProvider.getExRate(currency);
    BigDecimal convertedAmount = foreignCurrencyAmount.multiply(exrate);
    LocalDateTime validUntil = LocalDateTime.now(clock).plusMinutes(30);
    
    return new Payment(orderId, currency, foreignCurrencyAmount, exRate, convertedAmount, validUntil);
  }
}

외부로부터 주입 받는 Clock을 테스트에서 유용하게 사용할 수 있다.
- ExRateProviderStub처럼 조작한 Clock을 빈으로 띄우면 된다.

@Configuration
public class TestPaymentConfig {
  @Bean
  public PaymentService paymentService() { return new PaymentService(exRateProvider()); }
  
  @Bean
  public ExRateProvider exRateProvider() { return new ExRateProviderStub(BigDecimal.valueOf(1_1000)); }
  
  // 항상 고정된 시간을 가지는 시계를 빈으로 구성
  @Bean
  public Clock clock() { return Clock.fixed(Instant.now(), ZoneId.systemDefault());
}

@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = TestObjectFactory.class)
class PaymentServiceSpringTest {
  @Autowired
  private PaymentService paymentService;
  @Autowired
  private Clock clock; // 고정된 시간을 가지는 Clock

  // ...

  @Test
  void validUntil() throws IOException {
    Payment payment = paymentService.prepare(1L, "USD", BigDecimal.TEN);
  
    // valid until이 prepare() 30분 뒤로 설정됐는가?
    LocalDateTime now = LocalDateTime.now(this.clock);
    LocalDateTime expectedValidIntil = now.plutMinutes(30);
    
    assertThat(payment.getValidUntil()).isEqualTo(expectedValidUntil);
  }
}

도메인 오브젝트 테스트 (테스트의 꽃)

도메인 모델 아키텍처 패턴

도메인 로직, 비즈니스 로직을 어디에 둘 지 결정하는 패턴
- 트랜잭션 스크립트 - 서비스 메소드 (PaymentService.prepare)
- 도메인 모델 - 도메인 모델 오브젝트 (Payment)

public class PaymentService {
  // ...
  public Payment prepare(Long orderId, String currency, BigDecimal foreignCurrencyAmount) throws IOException {
    BigDecimal exRate = exRateProvider.getExRate(currency);
    BigDecimal convertedAmount = foreignCurrencyAmount.multiply(exrate);
    LocalDateTime validUntil = LocalDateTime.now(clock).plusMinutes(30);
    
    return new Payment(orderId, currency, foreignCurrencyAmount, exRate, convertedAmount, validUntil);
  }
}

기존 비즈니스 로직은 위와 같다.
이 로직을 도메인에 구현한다면 어떨까?
- Payment 생성을 팩토리 메서드를 통해 의미 있는 로직을 넣어보자.

public class Payment {
  // ...
  
  public static Payment createPrepared(Long orderId, String currency, BigDecimal foreignCurrencyAmount, BigDecimal exRate,
                                       LocalDateTime now) {
    BigDecimal convertedAmount = foreignCurrencyAmount.multiply(exrate);
    LocalDateTime validUntil = now.plusMinutes(30);
    
    return new Payment(orderId, currency, foreignCurrencyAmount, exRate, convertedAmount, validUntil);
  }
}

로직이 도메인으로 넘어가면 서비스 로직은 매우 단순해진다.
- 핵심 로직은 도메인으로
- 서비스 로직은 주로 의존하는 다른 오브젝트에 요청 및 도메인을 호출하는 역할만 하게 된다.

public class PaymentService {
  // ...
  public Payment prepare(Long orderId, String currency, BigDecimal foreignCurrencyAmount) throws IOException {
    BigDecimal exRate = exRateProvider.getExRate(currency);
  
    return Payment.createPrepared(orderId, currency, foreignCurrencyAmount, exRate, LocalDateTime.now(clock));  
  }
}

Payment 안에 중요한 로직을 넣어 두었으니 PaymentTest가 필요하다.
- 일반적으로 도메인 테스트는 매우 간단해진다.
- 서비스 테스트 때 처럼 많은 구성을 고려하지 않아도 된다.
  - 환율 정보를 어디서 가져왔는지 고려하지 않아도 됨

@Test
void createPrepared() {
  Clock clock = Clock.fixed(Instant.now(), ZoneId.systemDefault());
  
  Payment payment = Payment.createPrepared(
    1L, "USD", BigDecimal.TEN, BigDecimal.valueOf(1_000), LocalDateTime.now(clock)
  );
  
  assertThat(payment.getConvertedAmount()).isEqualByComparingTo(BigDecimal.valueOf(10_000));
  assertThat(payment.getValidUntil()).isEqualTo(expectedValidUntil);
}

도메인 모델 패턴의 장점
- 테스트 만들기가 쉬워진다.
- 테스트가 빠르다.
- 도메인 내부의 핵심 로직은 재사용 가능하고 응집도가 높아진다.