Threat Stack이 컨테이너를 사용하여 마이크로서비스 테스트를 자동화하는 이유

마이크로서비스는 올바르게 설계하더라도 테스트하기 어려울 수 있습니다. 하지만 시스템 아키텍처가 수십 또는 수백 개의 연결된 서비스가 끊임없이 변화하는 인프라에서 소프트웨어 플랫폼을 구성하는 지점까지 발전하면, 귀하와 귀하의 팀이 담당하는 제품을 테스트하는 것은 엄청나게 복잡한 작업이 됩니다. 이런 환경에 맞춰 테스트 자동화를 작성하는 것은 어렵기 때문에 작성하는 테스트에서 최대한의 가치를 얻어내는 것이 중요합니다.

Threat Stack에서는 회색 상자 기능 테스트의 한 형태인 시스템 통합 테스트를 작성하고, 컨테이너화된 테스트 환경을 실행하기 위해 Docker를 선택했습니다.

다른 유형의 테스트에는 어떤 문제가 있나요?

일부 조직은 여전히 전통적인 테스트 모델에 의존하고 있으며, 이 모델에서는 화이트 박스 테스트와 블랙 박스 테스트가 충분한 보완적 테스트 전략으로 간주됩니다. 이러한 요소는 여전히 소프트웨어 적격 심사에서 중요한 역할을 하지만, 소프트웨어를 자신 있게 출시하는 데 필요한 피드백을 제공하기에는 더 이상 충분하지 않습니다.

이러한 유형의 환경에서 블랙박스 사용자 수용 테스트는 너무 광범위하게 집중되어 있으며, 이에 의존하면 출시 시간 전략에 심각한 영향을 미칠 수 있습니다.

• 테스트를 실행하는 데 할당된 시간 내에 테스트할 수 있는 시나리오가 너무 많기 때문에 적절한 적용 범위가 제공되지 않습니다.
• 이 기능은 장시간 실행되며, 애플리케이션에서 제어할 수 없는 요소로 인해 시간이 초과되는 경우가 많습니다.
• 빌드 시점이 아닌, 서비스가 배포된 후에 실행되어야 하므로 피드백과 제품 개발이 더욱 분리됩니다. 테스트 엔지니어링을 주도하는 좌측 이동 철학에서 이 테스트에만 의존하면 조직의 경쟁력이 약해집니다.
• 이러한 테스트는 블랙박스 테스트이므로 실패 원인을 파악하는 것이 엄청나게 어려운 작업이 될 수 있습니다.
• 개발자가 쉽게 작성하거나 유지관리할 수 없습니다.

반면, 화이트박스 단위 테스트는 너무 좁은 범위에 초점을 맞추고 있으며 소프트웨어 시스템 기능을 평가하는 데 종종 잘못 사용됩니다.

• 이는 구성 요소 또는 다른 서비스와 상호 작용하는 서비스의 실제 동작을 고려하지 않습니다.
• 유지할 만큼 가치가 없고 무의미한 시나리오를 테스트할 수 있습니다.
• 코드의 작은 변경 사항에 대해서도 대량의 테스트를 지속적으로 업데이트해야 하는 개발자에게는 부담스러울 수 있습니다.
• 테스트 엔지니어가 쉽게 작성하거나 유지관리할 수 없습니다.

왜 시스템 통합 테스트에 집중해야 합니까?

Threat Stack 테스트 엔지니어는 모든 서비스를 테스트하기 위해 시스템 통합 테스트에 점점 더 의존하고 있습니다. 이는 테스트 범위를 극대화하는 동시에 다양한 운영 조건에서 애플리케이션이 제대로 작동하는지 확인하는 데 필요한 속도와 구체성을 제공하는 방법입니다.

통합 테스트는 외부 구성 요소와 인터페이스할 때 테스트 중인 소프트웨어나 시스템의 동작에 초점을 맞춘 회색 상자 테스트입니다. 예를 들어:

• 데이터 저장소, 예: PostgreSQL, Cassandra, ElasticSearch
• 메시지 브로커(예: Kafka)
• HTTP 서버

즉, 행동을 검증하기 위해 상호작용할 수 있는 소프트웨어입니다. Threat Stack에서는 실제 상황을 재현하는 기능 테스트를 주로 실행하지만, 테스트 대상 동작은 컨테이너화된 환경의 경계에서 멈추어 원치 않는 외부 상호 작용을 방지합니다.

이러한 테스트는 마이크로서비스와 긴밀하게 결합되어 있으므로 자동화된 테스트에서 테스트 중인 서비스의 코드를 검사하고 통합하여 코드에서 지속적으로 실행할 영역을 식별할 수 있다는 이점이 있습니다. 또한, 이러한 테스트는 제품 관리자와 QA 엔지니어 등 개발자가 아닌 사용자도 테스트 중인 동작을 더 쉽게 이해할 수 있도록 사용자 수용 테스트로 작성할 수 있습니다.

다시 말해서:

몇 가지 조건이 주어진 경우

서비스가 이 입력을 수신하는 경우(또는 이 조건이 서비스에 영향을 미치는 경우)

그러면 서비스는 예상한 대로 동작하고 예상한 부작용을 생성합니다.

이러한 기능 테스트는 이해하고 작성하기 쉬울 뿐만 아니라 마이크로서비스의 코드와 긴밀하게 결합되어 있어 개발자가 개발 프로세스 전반에 걸쳐 쉽게 실행하고 업데이트할 수 있으며, 이후 전담 테스트 엔지니어가 실행하고 업데이트할 수도 있습니다.

왜 컨테이너를 사용하나요?

컨테이너는 테스트 시스템에 매우 유용합니다. 테스트 기간 동안 최소한의 리소스로 테스트 환경을 빠르게 재생성할 수 있고 테스트가 끝나면 쉽게 정리할 수 있기 때문입니다. 대부분의 블랙박스 테스트 자동화와 달리, 통합 테스트를 수행하기 위해 비용이 많이 들고 항상 작동하는 테스트 환경이 필요하지 않습니다. 테스트를 실행하면 마이크로서비스의 동작을 테스트 환경에서 재현할 수 있습니다. 

프로덕션에서 마이크로서비스의 환경을 미러링하는 컨테이너화된 환경을 정의하면 테스트 프레임워크는 테스트 중인 구성 요소 또는 마이크로서비스와 인터페이스하는 외부 클라이언트 또는 모의 서비스가 됩니다. 이렇게 하면 테스트 코드가 테스트의 모든 측면을 주도하므로 테스트의 더 많은 측면을 제어할 수 있습니다.

시작할 때 Docker는 컨테이너화된 환경을 빠르게 구축하기에 좋은 플랫폼입니다. Docker Compose를 사용하면 동일한 코드를 사용하여 로컬이나 CI에서 테스트 중인 애플리케이션의 섹션을 쉽게 정의하고 실행할 수 있습니다. 귀하의 조직에서 Kubernetes , AWS EKS , AWS Fargate 와 같은 다른 컨테이너 인프라 도구와 서비스를 지원하는 경우 해당 도구와 서비스를 사용하여 테스트 환경을 배포할 수도 있습니다.

결론

궁극적으로 다른 유형의 자동화가 아닌 통합 테스트에 테스트 노력을 집중하기로 결정하면 두 가지 큰 이점이 있습니다.

• 마이크로서비스 테스트는 배포에 앞서 실행되도록 왼쪽으로 이동되어 반복적 개발에 대한 피드백을 더 빠르게 얻을 수 있습니다.
• 실제 서비스와 구성 요소에 대해 테스트를 실행하므로 테스트 범위 격차가 줄어들지만 기능 테스트는 계속 실행됩니다.