계약 테스트란 무엇입니까? 지식 가이드-JS 튜토리얼-php.cn

What is Contract testing: A knowledge guide
사용자 인증, 제품 카탈로그, 주문 처리 등 다양한 서비스가 있는 전자상거래 플랫폼을 예로 들어보겠습니다. 이러한 서비스는 API를 통해 통신합니다. 예를 들어 주문 처리 서비스는 카탈로그 서비스에서 제품 세부정보를 가져와야 합니다.

계약 테스트를 통해 이러한 서비스 간의 계약(주문 서비스가 제품 카탈로그 서비스에서 기대하는 데이터 지정)이 일관되게 유지되는지 확인합니다.

What is Contract testing: A knowledge guide

계약 테스트란 무엇입니까?

계약 테스트는 마이크로서비스 아키텍처의 다양한 서비스 간 통신이 합의된 사양과 일치하는지 확인합니다. 소비자(다른 서비스를 호출하는 서비스)와 공급자(호출되는 서비스) 간의 상호 작용이 미리 정의된 "계약"을 준수하는지 확인합니다.

이 계약은 API 또는 서비스에 대한 입력과 출력을 정의하여 양 당사자가 데이터 형식, 유형 및 응답 구조를 이해하고 동의하도록 보장합니다.

개발 프로세스 초기에 불일치를 감지하고, 통합 문제를 줄이고, 한 서비스의 변경 사항으로 인해 다른 서비스의 기능이 실수로 중단되지 않도록 하는 데 도움이 되는 공식 계약이라고 상상해 보세요.

계약 테스트를 언제 사용해야 합니까?

마이크로서비스 아키텍처: 마이크로서비스 환경에서는 여러 서비스가 서로 상호 작용합니다. 서비스가 다른 서비스의 API에 의존하는 경우 계약 테스트를 통해 예상되는 데이터 형식과 구조가 일관되게 유지되는지 확인합니다.
API 개발: API를 개발하거나 업데이트할 때 계약 테스트를 구현하면 팀에서 한 서비스의 변경 사항으로 인해 종속 서비스와의 통합이 중단되지 않는지 확인할 수 있습니다.
타사 통합: 애플리케이션이 외부 서비스 또는 API와 통합되는 경우 계약 테스트를 통해 타사 제공업체의 변경 사항으로 인해 애플리케이션 기능이 중단되지 않는지 확인할 수 있습니다.
팀 간 협업: 서로 다른 팀이 상호 연결된 서비스에 대해 작업할 때 계약 테스트는 API 사양에 대한 명확한 의사소통과 기대치를 유지하여 오해의 가능성을 줄이는 데 도움이 됩니다.

계약 테스트를 사용하는 이유

문제 조기 감지: 계약 테스트를 통해 팀은 개발 주기 초기에 통합 문제를 식별하고 해결할 수 있어 후기 단계 디버깅과 관련된 시간과 비용을 절약할 수 있습니다.
신뢰성 향상: 소비자와 생산자 모두가 합의된 계약을 준수하는지 검증함으로써 계약 테스트는 서비스 상호 작용의 신뢰성을 높여 더욱 안정적인 애플리케이션을 제공합니다.
더 빠른 개발 주기: 계약 테스트를 통해 팀은 각 서비스를 독립적으로 작업할 수 있으므로 지속적인 통합 확인 없이도 개발 및 배포 주기가 더 빨라집니다.
주요 변경 위험 감소: 대부분의 경우 주요 변경에 대한 안전망 역할을 하여 한 서비스에 대한 업데이트가 다른 서비스의 기능을 실수로 방해하지 않도록 보장합니다.
문서화 및 명확성: 계약은 API 상호 작용에 대한 기대치를 간략하게 설명하는 일종의 살아있는 문서 역할을 하므로 개발자가 서비스 통신 방법을 더 쉽게 이해할 수 있습니다.

다양한 유형의 계약 테스트

계약 테스트는 여러 유형으로 분류할 수 있으며, 주로 마이크로서비스 아키텍처의 서비스 간 상호 작용과 API 개발에 중점을 둡니다. 여기서는 이 두 가지 상황에서 계약 테스트가 구체적으로 어떻게 적용되는지 살펴보겠습니다.

마이크로서비스 중심: 마이크로서비스 환경에서는 소비자 중심 계약 테스트가 중요합니다. 이 접근 방식은 소비자 서비스가 생산자 서비스와 상호 작용하는 방식에 대한 기대치를 정의하는 소비자의 관점에 중점을 둡니다.

예를 들어 결제 서비스가 사용자 인증 서비스에 의존하는 경우 결제 서비스는 계약에서 필수 요청 매개변수와 예상 응답 형식을 지정합니다. 이렇게 하면 인증 서비스에서 변경한 내용으로 인해 결제 서비스 기능이 중단되지 않습니다.
API 기반: API 개발의 맥락에서 공급자 계약 테스트는 생산자 서비스가 소비자가 정의한 계약을 준수하는지 확인합니다. 이러한 유형의 테스트는 API가 지정된 요청에 올바르게 응답하는지 검증하는 데 필수적입니다.

예를 들어, 제품 카탈로그 서비스가 제품 세부 정보를 검색하기 위한 API를 제공하는 경우 공급자 계약 테스트를 통해 서비스가 예상 데이터 구조와 값을 일관되게 반환하는지 확인합니다. 계약에 대해 테스트를 실행함으로써 개발자는 API를 기반으로 하는 소비자 서비스를 실수로 중단하지 않을 것이라는 확신을 갖고 API를 업데이트하거나 개선할 수 있습니다.

계약 테스트를 수행하는 도구

협약:

What is Contract testing: A knowledge guide

개요: Pact는 특히 소비자 중심 계약 테스트에서 가장 널리 사용되는 계약 테스트 프레임워크 중 하나입니다.
특징: 여러 프로그래밍 언어를 지원하고 소비자 서비스에서 계약을 정의한 다음 공급자 서비스에서 이를 확인할 수 있습니다
사용 사례: 다양한 환경에서 소비자 중심 계약 테스트를 구현하려는 팀에 적합합니다.

케플로이

개요: Keploy는 계약 테스트를 자동으로 생성 및 실행하여 수동 작업을 크게 줄이고 오류를 최소화
하여 계약 테스트를 단순화하는 시장의 새로운 테스트 도구입니다.
특징: API 상호 작용을 기록하고 재사용 가능한 테스트 사례를 생성하여 사용자가 손쉽게 테스트를 생성할 수 있습니다. 이러한 상호 작용은 계약의 기초를 형성합니다. 그런 다음 테스트를 별도로 실행하여 계약의 유효성을 검사하여 실제 서비스 종속성을 실행할 필요 없이 API 상호 작용이 계약에 설정된 기대치를 충족하는지 확인합니다.
사용 사례: 품질 저하 없이 개발 주기를 단축하여 API 테스트 효율성과 안정성을 향상시키려는 팀에 적합합니다.

Spring Cloud 계약:

What is Contract testing: A knowledge guide

개요: Spring 생태계의 일부인 Spring Cloud Contract는 소비자와 공급자 계약 테스트 모두에 도움이 됩니다.
기능: Groovy DSL 또는 YAML을 사용하여 계약을 생성하고 양측에 대한 테스트를 자동으로 생성할 수 있습니다.
사용 사례: Spring 개발 라이프사이클에 완벽하게 통합되므로 이미 Spring Boot를 사용하고 있는 팀에 가장 적합합니다.

우체부:

What is Contract testing: A knowledge guide

개요: Postman은 전문 도구처럼 본격적인 계약 테스트를 제공하지는 않지만 스키마 검증 및 자동화된 테스트 스크립트를 통해 API가 사전 정의된 사양을 준수하는지 확인하는 데 도움이 될 수 있습니다.
기능: OpenAPI 사양을 사용하여 API 스키마를 생성 및 검증하고 테스트를 실행하여 이러한 계약을 준수하는지 확인할 수 있습니다.
사용 사례: 수동 테스트와 함께 계약 테스트를 API 개발 워크플로에 통합하려는 팀에 유용합니다.

계약 테스트의 장점과 단점

Pros	Cons
Ensures service compatibility across microservices.	Complex to set up and maintain in large systems.
Validates expectations between consumer and provider.	Requires careful planning and design considerations.
Decouples teams, allowing independent development.	Requires coordination between provider and consumer teams.
Enables teams to work autonomously on services.	Needs regular communication to maintain alignment.
Prevents breaking changes early in the pipeline.	May not catch all integration issues.
Identifies discrepancies before deployment occurs.	Requires complementary testing for thorough coverage.
Improves communication between teams.	Needs constant updates as contracts evolve.
Establishes clear expectations for service interactions.	Contracts must be regularly maintained and refined.
Reduces the need for end-to-end tests.	Requires additional tools and frameworks.
Focuses testing efforts on defined interactions.	Teams must invest time in learning and integration.

장점 단점 마이크로서비스 전반에 걸쳐 서비스 호환성을 보장합니다. 대규모 시스템에서는 설정 및 유지 관리가 복잡합니다. 소비자와 제공자 간의 기대치를 검증합니다. 신중한 계획과 설계 고려가 필요합니다. 팀을 분리하여 독립적인 개발을 가능하게 합니다. 공급업체와 소비자 팀 간의 조정이 필요합니다. 팀이 자율적으로 서비스 작업을 수행할 수 있습니다. 조정을 유지하려면 정기적인 의사소통이 필요합니다. 파이프라인 초기에 주요 변경 사항을 방지합니다. 모든 통합 문제를 포착할 수는 없습니다. 배포가 발생하기 전에 불일치를 식별합니다. 철저한 적용을 위해서는 보완적인 테스트가 필요합니다. 팀 간의 의사소통을 향상시킵니다. 계약이 발전함에 따라 지속적인 업데이트가 필요합니다. 서비스 상호작용에 대한 명확한 기대치를 설정합니다. 계약서는 정기적으로 유지되고 개선되어야 합니다. 종단간 테스트의 필요성이 줄어듭니다. 추가 도구와 프레임워크가 필요합니다. 정의된 상호작용에 테스트 노력을 집중합니다. 팀은 학습과 통합에 시간을 투자해야 합니다.

결론

계약 테스트는 마이크로서비스 아키텍처에서 필수적이며 소비자와 공급자 서비스 간의 명확한 통신을 보장합니다. 서비스가 API를 통해 통신하는 방식에 중점을 두어 문제를 조기에 파악하고 한 서비스가 실수로 다른 서비스를 중단시키는 것을 방지합니다. 계약 테스트가 엔드 투 엔드 테스트를 대체하지는 않지만 서비스 간의 특정 상호 작용으로 초점을 좁혀 이를 보완합니다.

그리고 테스트 전략의 일부로 사용하면 통합 문제를 크게 줄이고 코드를 원활하게 실행하는 데 도움이 될 수 있습니다.