9.1 마이크로서비스 아키텍처 테스트 전략
테스트 개요
TC: 어떤 목표를 달성하기 위해 개발된 테스트 입력, 실행 조건, 기대 결과의 집합
SUT: System Under Test, 테스트 대상 시스템
자동화 테스트
다음 4단계로 구성된다
- 설정: 테스트 대상 클래스 생성, 원하는 동작을 수행할 수 있는 상태로 초기화
- 실행: SUT 호출 (테스트 대상 클래스의 메서드를 호출)
- 확인: assertion
- 정리: DB 트랜잭션 롤백 등
설정(초기화), 정리 단계 같은 경우 따로 공통화
목/스텁을 이용한 테스트
- 스텁: SUT에 값을 반환
- 목: 정확하게 디펜던시를 호출했는지 확인, 목은 스텁의 일종
테스트 종류
- 단위 테스트: 클래스 단위처럼 작은 부분
- 통합 테스트: 인프라 서비스 및 타 애플리케이션 서비스와 잘 연동되는지
- 컴포넌트 테스트: 인수 테스트
- 종단 간 테스트: 전체 애플리케이션에 대한 인수 테스트
테스트 사분면: 테스트 분류 기준
암튼 이런게 있다.....
마이크로서비스 테스트
MSA 에서는 REST, gRPC 처럼 동기 프로토콜을 이용해 요청/응답하는 서비스도 있고, 발행/구독 스타일로 통신하는 서비스도 있다.
통신 기반이기에 종단 간 테스트는 가능한 작성하지 않는 것이 좋고, 서비스만 따로 떼어내서 테스트 작성하는 것이 좋다.
컨슈머 주도 계약 테스트
- 프로바이더의 API가 컨슈머가 기대한 바와 일치하는지 확인하는 프로바이더에 대한 통합 테스트
- 비즈니스 로직을 확인하는게 아님, REST API 의 컨슈머 계약 테스트는 사실상 목 컨트롤러 테스트
- 서비스가 클라이언트의 기대에 부합하는지 확인하는 테스트
서비스 테스트: 스프링 클라우드 컨트랙트
컨슈머/프러바이더 간의 HTTP 요청/응답 같은 계약을 그루비 DSL로 작성할 수 있게 해준다.
(API게이트웨이: 컨슈머 / 주문서비스: 프로듀서)
- 하나 이상의 계약 작성, 컨슈머가 전송할 HTTP 요청과 프로바이더의 HTTP 응답 작성
- 프로바이더는 계약 테스트로 테스트, 코드는 스프링 클라우드 컨트랙트에 자동 생성됨
- 프로바이더는 테스트한 계약을 메이븐 저장소로 발행
- 프로바이더가 발행한 계약을 이용해 테스트 작성
이 방식을 사용하면 주문이랑 직접 통신할 필요는 없다..
컨슈머 계약 테스트: 메시징 API
REST 방식 말고 비동기 통신도 존재한다.
- 프로바이더 테스트: 계약의 요청 메시지를 API에 넘겨 호출하고 그 결과 반환된 응답이 계약의 응답과 같은지 확인
- 컨슈머 테스트: 계약을 이용해 스텁 구독기 구성하고, 스텁 구독기가 계약의 요청 메시지를 리스닝하다가 응답 반환
??? 흠 10장에 예제 나온다고 한다
배포 파이프 라인
- 사전-커밋 테스트 단계: 개발자가 단위 테스트 실행
- 커밋 테스트 단계: 컴파일 후 단위 테스트 실행 및 정적 코드 분석 수행
- 통합 테스트 단계
- 컴포넌트 테스트 단계: 서비스 컴포넌트 테스트 실행
- 배포
💻 ☕️ 🏝 🍑 🍹 🏊♀️