배경.

최근에 새로운 일을 시작한 저는 여전히 건강한 양의 사기꾼 증후군을 앓고 있는 전조등의 사슴이 되는 단계에 있습니다. 코드베이스에 익숙해지지만 여전히 가치를 가져오려고 노력하면서 가능한 한 빨리 도메인을 흡수하려고 합니다. 내 관심을 끈 코드베이스 영역 중 하나는 integration tests라이브 환경에서 실행 되는 영역이었습니다 .

이것은 내가 유일하게 해본 것처럼 개인적으로 처음이었습니다.

• 표를 구동 하여 테스트 주장을 google/go-cmp.
• docker-compose및 PAW/Postman을 사용한 수동 통합 테스트 .

토론 후에 나는 두 가지 접근 방식을 구별할 수 있는 이름을 찾기 위해 검색을 했고 Martin Fowler가 바로 이것에 대해 논의한 기사를 발견 했습니다.

좁은 통합 테스트

- 내 서비스에서 별도의 서비스와 통신하는 코드 부분만 실행

- 프로세스 또는 원격에서 해당 서비스의 테스트 더블을 사용합니다.

- 따라서 종종 단위 테스트보다 더 크지 않은 좁은 범위의 테스트로 구성됩니다(일반적으로 단위 테스트에 사용되는 동일한 테스트 프레임워크로 실행됨).

광범위한 통합 테스트

- 실질적인 테스트 환경과 네트워크 액세스가 필요한 모든 서비스의 라이브 버전 필요

- 상호 작용을 담당하는 코드뿐만 아니라 모든 서비스를 통해 코드 경로를 실행합니다.

실천하기.

올 ory/dockertest와 mountebank! Dockertest를 사용하면 테스트 스위트 내에서 도커 컨테이너를 생성할 수 있고 mountebank를 사용하면 "임포스터"라고 하는 스텁 데이터를 사용하여 이러한 외부 종속성에 대한 테스트 더블을 생성할 수 있습니다. 우리가 해야 할 일은

• dockertest를 사용하여 주어진 임포스터 파일로 mountebank 도커 컨테이너를 시작하십시오.
• 새로 생성된 도커 컨테이너에 있는 임포스터의 주소와 포트를 외부 서비스 클라이언트에 전달합니다.

이것은 사기꾼의 아주 기본적인 예이지만 , 로 /test요청 GET하면 상태 200을 반환합니다.

다음은 임포스터로 로드된 컨테이너를 생성하고 이에 대해 테스트 스위트를 실행하는 예입니다.