토비의 스프링 6 | 섹션 3 요약

[all-cloudz]

섹션3. 테스트

• 수동 테스트
  • 보고 싶은 내용을 콘솔에 출력하여 직접 확인하는 것을 반복하여 테스트를 진행
  • 하나의 기능을 개발하는 과정에서 확인하기에는 편하고 좋음
  • 기능이 많아지면 일일히 확인할 수 없을테니 장기적으로 유지할 수 없는 방법
• 자동 테스트
  • 기왕이면 테스트의 크기는 작게 해보자 ⇒ Unit Test
  • 테스트는 왜 하지? 하면 뭐가 좋지? 테스트 코드는 얼마나 짜야하는거지?
  • Java의 Testing Framework = JUnit + AssertJ
    • 자주 사용하는 애노테이션: @Test, @BeforeEach, @ParamaterizedTest, @DisplayName
    • 테스트 코드의 단계별 구성: 준비(Given), 실행(When), 검증(Then)
    • 테스트 기본 원칙
      • 테스트 코드에는 가능하다면 성공과 실패를 모두 담는 것을 권장
      • 테스트는 가능한 빠르게 실행되어야 함
      • JUnit은 각 테스트마다 테스트 클래스의 인스턴스를 새로 만듦 ⇒ 각 테스트는 독립적이어야 함
  • 테스트 코드와 의존성
    • 외부 컴포넌트(협력자)가 테스트 대상에 관여 ⇒ 테스트 코드를 짜기가 참 아주 많이 난감...
    • 테스트 코드를 위한 두 가지 DI 방식
      • Base Task: 협력자를 Stub으로 대체 = 임포스터(Imposter, Test Double)
        • 테스트 목적에 맞게 직접 인터페이스를 구현
        • Mockito를 사용
      • 방법1. DI를 이용하여 테스트 객체를 직접 생성 (수동 DI)
      • 방법2. Spring DI를 이용해서 테스트용 협력자 주입
        • @ExtendWith(SpringExtention.class)
        • @ContextConfiguration : 테스트를 위해 어떤 컨텍스트를 사용할 것인지 지정 ⇒ 스프링 컨테이너에 로드
        • @Autowired : 스프링 컨테이너의 특정 빈을 바인딩
      • 수동 DI vs 스프링 DI
        • 수동 DI는 테스트 코드가 동작하는 속도가 빠름, 개발도 빠르게 할 수 있음
        • 스프링 DI는 테스트 코드와 Configuration을 분리 ⇒ 코드가 확장되었을 때 Configuration만 고치면 됨
    • 도메인 오브젝트 테스트
      • DTO가 로직을 가진다면?, 비즈니스 로직을 DTO 안으로 집어 넣는다면? ⇒ 도메인화
      • 도메인을 테스트하는 게 훨씬 쉽다, 외부 의존성을 다 DI로 밀어넣으면 되니까.
    • 추가 주제: Mock vs Stub
• 학습 테스트 ⇒ Clock에 적용해보기
  • 내가 직접 만들지 않았지만 이용해야 하는 코드에 대한 테스트 ⇒ 테스트 대상의 동작 방식을 확인하기에 유용
  • Spring DI를 이용한 테스트는 확실히 변경에 대해서 최소한의 코드 변경만 해도 되니까 좋아보이긴 함

[Leehyoungwoo]

테스트

수동 테스트의 한계

• 프린트된 메세지를 수동으로 확인하는 방법은 불편
• 사용자 웹 UI까지 개발한 뒤에 확인하는 방법은 테스트가 실패했을 때 확인해야할 코드가 많음
• 테스트할 대상이 많아질수록 검증하는데 시간이 많이 걸리고 부정확함

작은 크기의 자동 수행되는 테스트(Automated Test)

개발자가 만드는 테스트

• 개발한 코드에 대한 검증 기능을 코드로 작성
• 자동으로 테스트를 수행하고 결과를 확인
• 테스팅 프레임워크를 활용
• 테스트 작성과 실행도 개발 과정의 일부

JUnit5

• @Test 테스트 메서드
• @BeforeEach 테스트
  • 각 테스트 전에 실행
• 모든 테스트 실행마다 새로운 인스턴스가 만들어짐
  • 각 실행마다 독립적으로 실행되어야 함

PaymentService 테스트의 문제점

• 강의 코드

  package tobyspring.hellospring.payment;
  
  import org.junit.jupiter.api.DisplayName;
  import org.junit.jupiter.api.Test;
  import tobyspring.hellospring.exrate.WebApiExRateProvider;
  
  import java.io.IOException;
  import java.math.BigDecimal;
  import java.time.LocalDateTime;
  
  import static org.assertj.core.api.Assertions.assertThat;
  
  class PaymentServiceTest {
  
      @Test
      @DisplayName("prepare 메서드가 요구사항 3가지를 잘 충족했는지 검증")
      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(payment.getExRate().multiply(payment.getForeignCurrencyAmount()));
          //원화환산금액유효시간 계산
          assertThat(payment.getValidUntil()).isAfter(LocalDateTime.now());
          assertThat(payment.getValidUntil()).isBefore(LocalDateTime.now().plusMinutes(30));
      }
  }

• 제어할 수 없는 외부 시스템에 문제가 생기면?

  • 외부API 환율 정보이 관여

• ExRateProvider가 제공하는 환율 값으로 계산한 것인가?

• 환율 유효 시간 계산은 정확한 것인가?

테스트의 구성 요소

• 테스트 대상 (SUT)

• 테스트

• 협력자

  • 임포스터? 테스트 더블(대역)?

• BigDecimal은 유효자리수도 따지기 때문에 isEqualByComparingTo 로 비교하는게 나음

테스트와 DI

수동 DI를 이용하는 테스트

• 테스트용 협력자/의존 오브젝트를 테스트 대상에 직접 주입하고 테스트

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

• 테스트용 협력자/의존 오브젝트를 스프링의 구성 정보를 이용해서 지정하고 컨테이너로부터 테스트 대상을 가져와서 테스트
• @ContextConfiguration, @Autowired

학습 테스트 (Learing Test)

• 직접 만들지 않은 코드, 라이브러리, 레거시 시스템에 대한 테스트
• 테스트 대상의 사용방법을 익히고 동작 방식을 확인하는데 유용
• 외부 기술, 서비스가 버전이 올라갔을 때 이전과 동일하게 동작하는지 확인

도메인 오브젝트 테스트

도메인 모델 아키텍처 패턴

• 도메인 로직, 비즈니스 로직을 어디에 둘지를 결정하는 패턴
  • 트랜잭션 스크립트
    • 서비스 메서드
  • 도메인 모델
    • 도메인 모델 오브젝트

[all-cloudz]

추가적으로 정리할 것

• [x] 테스트는 왜 하는걸까?
• [x] TDD에 대해서 간략히 조사하기
• [x] Mock, Stub, Spy, Fake 등의 테스트 대역 정리