마이크로서비스 아키텍처 구축 - 7장.테스팅

테스트의 종류

일반적으로 단위테스트 작성과 단위테스트를 통한 자동화 테스팅에는 익숙해져 있다. ( 나는 아직 그것도 부족하지만... ) 하지만, 분산 시스템 영역에서의 테스트를 어떻게 해야할까?

 

마이크로서비스에서의 테스팅은 광범위한 분야를 다룬다.

• 단위 테스팅 : 좁은 범위의 단위 테스트
• 속성(성능) 테스팅 : nGrinder와 같은 성능 테스트
• 인수 테스팅 : 넓은 범위의 end to end 테스트
• 탐색 테스팅 : 고객에 의한 최종 테스팅 

테스트를 작성하다 보면 자동화 테스트의 경우 얼마나 많이 작성해야 할지 모호할 때가 있다. 단위테스트야 커버리지 100% 가져가면 좋지만, 통합테스트는 얼마나 짜야할지 모호한 경우가 많다.

 

테스트의 범위

아래 쇼핑물을 예제로 테스트 종류를 살펴보자.

1. 단위 테스트

• 단위 테스트의 목표 : 기능의 핵심 동작 유뮤에 대한 빠른 피드백
• 다른 서비스 실행하지 않음
• 외부 파일, 네트워크 연결도 제한
• 빠른 테스팅

2. 서비스 테스트

• 외부 협업자(적립포인트 은행)을 stub으로 만들어서 테스트
• 개별 서비스를 테스트 ( 고객 서비스 )

3. end-to-end 테스트

• 시스템 전체에 대한 테스트
• 전체 테스트이기 때문에 강한 확신을 가질 수 있음
• 하지만, 마이크로서비스에 이걸 구현하긴 매우 까다로움 -> 단점이 좀 있음

테스트의 종류는 위와 같이 크게 3가지고 있고, 테스트는 많을 수록 좋을까?

이 책을 쓰신 분은 모놀리식 어플리케이션에서 4천개의 단위테스트, 1천개의 서비스테스트, 60개의 앤드 투 앤드 테스트를 작성하였다 한다. 하지만 테스트 시간이 너무 오래 걸리면서 피드백 관점에서는 매우 부정적인 영향을 끼치게 되었다 한다. 이러한 결과를 역피라미드 안티패턴이라고 한다. 이 패턴은 작은 범위의 테스트는 거의 없고 대부분 큰 테스트만 있는 경우를 말한다.

 

엔드 투 엔드 테스트의 단점

1. 어떤 팀에서 이 테스트를 만들어야 할까?

2. 얼마나 오래 걸릴까?

3. 엄청난 적체

4. 메타버전

 

성능 테스트

마이크로서비스에서 성능 테스트가 더 중요해진 이유는

• 다른 마이크로서비스들과 네트워크를 넘은 호출

때문이다. 이 때문에 성능 테스트는 모놀리틱 때보다 더 중요해졌다. 그렇다면 성능 테스트는 어떻게 진행해야 하는가?

• 모의 고객 수를 점차 증가시키면서 성능 테스트 해보기
• 실환경과 가능한 한 일치시키기

성능 테스트는 소요 시간이 오래 걸리기 때문에, 매주 매달마다 주기적으로 진행하는 것이 좋다.  성능 테스트는 실제 시스템의 성능 모니터링을 지원받아 수행해야 한다. ( 8장 포스팅 예정 ) 

 

네이버 오픈소스도 공부해봐야겠다.

https://nesoy.github.io/articles/2018-10/nGrinder-Start