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

354

2

부

구현

쳐내 테스트 중단이 발생하면 고객 마이크로서비스 자체의 문제로 매핑되도록 해야 한다.

7

장에서 살펴본 것처럼, 소프트웨어를 체크인하고 나서 자동화된 빌드가 수행하는 첫 번째 작

업 중 하나는 마이크로서비스용 바이너리 산출물을 생성하는 것이다. 예를 들어 해당 버전의

소프트웨어에 대한 컨테이너 이미지를 생성한다. 따라서 배포는 매우 간단하다. 하지만 다운스

트림 협업자 (서비스 )로 가장하려면 어떻게 처리해야 할까?

서비스 테스트 집합은 다운스트림 협업자를 쳐내고 테스트 중인 마이크로서비스를 스텁 서비

스에 연결하도록 구성해야 한다. 그런 다음 실제 마이크로서비스를 흉내 내기 위해 응답을 다

시 보내도록 스텁을 구성해야 한다.

9.3.19.3.1

목 또는 스텁 사용 목 또는 스텁 사용

다운스트림 협력자를 스텁하는 것과 관련해 이야기할 때는 테스트 중인 마이크로서비스의 알

려진 요청에 대해 미리 준비된 응답을 회신하는 스텁 마이크로서비스를 만든다는 것을 의미한

다. 예를 들어 스텁된 멤버십 마이크로서비스에 고객

123

의 잔액을 요청하면

15

,

000

을 반환

한다고 말할 수 있다. 테스트는 스텁이

0

번, 한 번 혹은

100

번 호출되는지 여부는 중요하지 않

다. 이에 대한 변형은 스텁 대신 목

mock

을 사용하는 것이다.

목을 사용할 때는 실제로 더 나아가 호출이 이뤄졌는지 확인한다. 기대한 호출이 이뤄지지 않

았다면 테스트는 실패한다. 이 방식을 구현하려면 우리가 만든 가짜 협업자는 더 영리해질 필

요가 있으며, 과도하게 사용되면 테스트가 ...