마이크로서비스에 테스트 자동화를 적용하는 것에 대해 알아보자. 수행 가능한 테스트의 종류를 이해하는 것이 중요하다
테스트의 종류
기술중심(개발자) - 단위 테스트, 성능 테스트
비지니스중심 - 인수 테스트, 탐색 테스트
각 테스트를 얼마나 많이 수행할 것인지는 시스템의 특성에 달려 있지만. 핵심은 시스템을 테스트하는 방법의 측면에서 여러 선택을 해야 한다는 것.
테스트의 범위
단위테스트 : 단일 함수 또는 메서드 (기능의 정상 동작 유무에 대한 빠른 피드백)
서비스테스트 : UI를 우회해서 서비스들을 직접 테스트
엔드 투 엔드 테스트 : 시스템 전체 (이 부분이 마이크로서비스 환경에서 까다롭다)
서비스 테스트
단위테스트와 다르게 서비스 테스트는 테스트하려는 서비스와 다른 서비스를 격리 시키는게 관건이다. 이를 위해 다른 협업자를 모두 스텁화 한다. 서비스테스트집합은 하위 협업자를 위한 스텁 서비스를 실행시켜야 하고 스텁 서비스들과 연결되는 환경에 고객 서비스를 구성한 다음 실 환경 서비스를 모방해 응답을 보내도록 스텁을 구성해야 한다.
엔드 투 엔드 테스트
엔트 투 엔트 테스트를 구현하기 위해선 다수의 서비스를 함께 배포해야 하고, 그 후 모든 서비스에 대한 테스트를 수행해야 한다. 따라서 더 넓은 범위를 다루긴 하지만 더 느리며 실패를 분석하기 어렵다.
- 변경되는 범위가 증가함에 따라 신뢰할 수 없는 케이스가 늘어난다.
- 다수의 팀이 연계되어 있을 확률이 높기 떄문에 누가 주도해야 할지에 대한 문제가 생긴다.
- 시간 소요가 상당하다. 피드백 주기가 길어 적체가 일어난다.
최선의 방법은 전체 시스템을 테스트 하는 소수의 핵심 여정에 집중하는 것.
소비자 주도 테스트
-
출시 후 테스팅
배포 전 테스팅을 통해서는 장애의 가능성을 완전히 없앨 수는 없다
- 배포를 릴리즈와 분리하기 : 스모크 테스트, 청색/녹색 배포
- 카날리아 릴리즈
교차기능 테스트
- 비 기능적 요구사항 : 일반적인 기능과 같이 단순히 구현될 수 없는 시스템의 특징을
성능 테스트
단