[MSA] 10. 마이크로서비스 테스트 2부

Jimin Lim·2024년 2월 3일
0

Architecture

목록 보기
20/23

10.1 통합 테스트 작성

통합 테스트: 인프라 테스트, 타 애플리케이션 서비스와 적절히 연동되는지 확인

통합 테스트는 종단 간 테스트처럼 전체 서비스를 실행시키지 않는다. 대신 테스트를 간소화하기 위해 아래 두 가지 전략을 사용한다.

1) 각 서비스의 어댑터 테스트
예를 들어 JPA 영속화 테스트는 정확히 저장되었는지 OrderRepository를 직접 테스트한다.

2) 9장에서 나온 계약 활용

계약의 용도는 컨슈머/프로바이더 둘 다 테스트해서 서로 바라보는 API가 일치하는가 확인하는 것, 테스트 대상이 컨슈머인지 프로바이더인지에 따라 다르다.

  • 소비자 쪽 테스트: 계약을 이용해 프로바이더를 모킹한 스텁을 구성할 수 있어 프로바이더 실행 필요 없음
  • 프로바이더 쪽 테스트: 디펜던시를 목으로 잡아 놓고 계약을 이용해 어댑터 테스트

10.1.1 통합 테스트: 영속화

DB 접근 로직이 잘 동작하는지 직접 저장하면서 테스트 해보는 것

10.1.2 통합 테스트: REST 요청/응답형 상호 작용

REST 요청/응답형은 REST 끝점 및 요청/응답 본문의 구조에 대한 테스트를 해야한다.

OrderServiceProxy 는 와이어목 기반의 HTTP 스텁 서버 호출하도록 한다. 와이어목을 관리하고 계약에 명시된 HTTP 요청에 응답하도록 구성하는 작업은 스프링 클라우드 컨트랙트의 몫이다.

계약 예제

1) 계약 생성

2) HTTP Base

    when(orderRepository.findById(OrderDetailsMother.ORDER_ID)).thenReturn(Optional.of(OrderDetailsMother.CHICKEN_VINDALOO_ORDER));
    RestAssuredMockMvc.standaloneSetup(controllers(orderController));

위와 같이 계약에 지정된 orderId로 원하는 Order를 반환하도록 구성한다.

3) 클라이언트 테스트

OrderServiceProxy 가 와이어목 포트에 요청하도록 구성한다. 그리고 각 테스트 메서드는 orderServiceProxy 를 호출해 정확한 값이 반환되는지, 기대한 예외가 던져지는지 확인한다.

10.1.3 통합 테스트: 발행/구독 스타일 상호 작용

발행/구독 스타일은 서로가 바라보는 메시지 채널 & 도메인 이벤트 구조가 서로 일치하는지 확인해야 한다.

1) 계약 작성

2) 프로바이더 테스트
스프링 클라우드 컨트랙트가 MessagingBase 생성함, publisher를 호출해 이벤트를 발행한다.

3) 컨슈머 테스트
테스트에서 OrderCreated 이벤트를 발생시키고 컨슈머에서 처리할 메서드를 호출했는지 확인한다.

10.1.4 통합 계약 테스트: 비동기 요청/응답 상호 작용

서비스의 메시징 프록시를 호출해 메시징 프록시가 계약대로 커맨드 메시지를 보내는지, 그리고 프록시가 응답 메시지를 적절히 처리하는지 확인

1) 계약

2) 소비자 쪽 테스트

KitchenServiceProxy로 커맨드 메시지를 전송하고 이 프록시가 기대되는 결과를 반환하는지 확인

3) 프로바이더 쪽 테스트

응답을 올바르게 전송해서 커맨드 메시지를 처리하는지 확인해야 한다.

10.2 컴포넌트 테스트 개발

  • 컴포넌트 테스트: 디펜던시를 스터빙하여 서비스를 따로 테스트

10.2.1 인수테스트 정의

인수 테스트는 유스 케이스에서 출발, 컴포넌트의 클라 관점에서 어떤 동작이 외부에 드러나야 하는지 기술한다.

10.2.2 인수테스트 작성: 거킨

거킨: 테스트 DSL
큐컴버: 거킨으로 작성한 테스트를 실행하는 자동화 프레임워크..

  • Given: 설정
  • When: 실행
  • Then, And: 확인

10.2.3 컴포넌트 테스트 설계

  • 인-프로세스 컴포넌트 테스트

    • 인-메모리 스텁과 목 디펜던시로 서비스 실행하는 것, @SpringBootTest
    • 배포 가능한 서비스를 테스트할 수 없다
  • 아웃-오브-프로세스 컴포넌트 테스트

    • DB, 메시지 브로커 등은 실제 인프라 서비스 사용 / 애플리케이션 서비스 형태의 디펜던시는 스텁으로 대체
    • 실행이 느리고 인프로세스 컴포넌트 테스트보다 더 취약함
  • 아웃-오브-프로세스 컴포넌트 테스트에서 서비스를 스터빙하는 방법

    • DSL을 스터빙한 와이어목으로 HTTP 스텁을 구성하는 것

10.3 종단 간 테스트 작성

  • 종단 간 테스트: 서비스 그룹 또는 전체 애플리케이션 대상

전체를 대상으로 하기에 느리고 취약하고 개발 소요 기간이 길다.

10.3.3 종단 간 테스트 실행

도커 컴포즈 파일로 모두 실행해서 테스트

profile
💻 ☕️ 🏝 🍑 🍹 🏊‍♀️

0개의 댓글