마이크로서비스 아키텍처 구축(전면 개정판)

364

2

부

구현

트 환경 없이도 요구에 따라 바로 대부분의 테스트를 수행할’ 가능성이 더 높다.

9.59.5

엔드투엔드 테스트를 피해야 할까? 엔드투엔드 테스트를 피해야 할까?

방금 설명한 단점이 있지만, 많은 사용자에게 엔드투엔드 테스트는 여전히 적은 수의 마이크로

서비스로 관리할 수 있으며 여전히 이러한 상황에서는 매우 합당하다. 하지만 서비스 수가

3

,

4

,

10

개 혹은

20

개라면 어떨까? 이와 같은 테스트 집합은 급속도로 비대해지고 최악의 경우

테스트 시나리오가 기하급수적으로 증가한다.

실제로 적은 수의 마이크로서비스가 있더라도 여러 팀이 엔드투엔드 테스트를 공유한다면 이

러한 테스트는 어려워지고, 공유된 엔드투엔드 테스트 집합을 사용하면 독립적인 배포 가능성

이라는 목표는 퇴색된다. 팀으로서 마이크로서비스를 배포하려면 이제 여러 팀이 공유하는 테

스트 집합을 통과해야 한다.

앞에서 설명한 엔드투엔드 테스트를 사용할 때 해결하려는 주요 문제 중 하나는 무엇인가? 새

로운 서비스를 운영 환경에 배포할 때는 변경 사항으로 인해 소비자가 중단되지 않도록 노력한

다.

5

.

4

.

1

절 ‘구조적 계약 위반 대 의미적 계약 위반’에서 자세히 다뤘듯이, 이제 마이크로서비

스 인터페이스에 대한 명시적 스키마를 사용하면 구조적 중단을 포착하는 데 유용하며 더 복잡

한 엔드투엔드 테스트의 필요성이 크게 줄어든다.

그렇지만 스키마는 의미적 중단, 즉 이전 버전과의 비호환성으로 인해 중단을 유발하는 동작의

변경 사항을 찾아낼 수 없다. 엔드투엔드 테스트는 이러한 ...