최신 마이크로서비스 아키텍처에서 애플리케이션은 종종 API를 통한 서비스 간 통신에 크게 의존합니다. 개발 중과 변경 후에도 이러한 API가 예상대로 계속 작동하는지 확인하는 것이 중요합니다. 이를 달성하는 효과적인 방법 중 하나는 소비자 중심 계약 테스트(CDCT)를 이용하는 것입니다. CDCT는 API를 사용하는 서비스(소비자)가 설정한 기대치를 서비스(생산자)가 준수하도록 보장하는 방법입니다.
이 가이드에서는 CDCT가 무엇인지, 어떻게 작동하는지, 안정적인 마이크로서비스 상호 작용을 보장하는 데 있어 CDCT의 중요성, Pact와 같은 도구를 사용하여 CDCT를 구현하는 방법을 살펴보겠습니다.
소비자 중심 계약 테스트란 무엇인가요?
소비자 중심 계약 테스트는 분산 아키텍처의 서비스 간 통신이 합의된 계약을 준수하는지 확인하는 테스트 전략입니다. API 자체가 올바르게 작동하는지 확인하는 것이 아니라 소비자 요구에 초점을 맞춘다는 점에서 기존 API 테스트와 다릅니다. API 소비자와 공급자 간의 계약은 소비자의 기대에 따라 정의되며 이 계약은 공급자의 구현을 기준으로 검증됩니다.
주요 용어:
• 소비자: API를 소비하는 서비스입니다.
• 제공자(Producer) : API를 제공하는 서비스입니다.
• 계약: 예상되는 API 동작을 지정하는 소비자와 공급자 간의 공식 계약입니다.
어떻게 작동하나요?
소비자 중심 계약 테스트의 중요성
분산 아키텍처, 특히 마이크로서비스의 경우 서비스 간의 종속성을 관리하는 것이 더욱 복잡해집니다. CDCT는 여러 가지 방법으로 이러한 복잡성을 완화하는 데 도움이 됩니다.
1. 생산 중 파손 방지
소비자는 필요한 것을 정의하므로 소비자의 기대를 충족하지 못하는 공급자의 API 변경 사항은 개발 파이프라인 초기에 포착됩니다. 이렇게 하면 호환되지 않는 변경으로 인해 생산 시스템이 중단될 위험이 줄어듭니다.
2. 디커플링 개발
소비자 중심 계약 테스트를 통해 소비자와 공급자는 독립적으로 개발할 수 있습니다. 이는 팀이나 서비스가 별도로 발전할 때 특히 유용합니다. 계약은 모든 개발 주기 동안 전체 통합 테스트 없이 통합이 예상대로 작동하도록 보장하는 인터페이스 역할을 합니다.
3. 더욱 빨라진 개발 주기
CDCT를 사용하면 소비자와 공급자 모두를 동시에 개발하고 테스트할 수 있어 개발 속도가 빨라집니다. 공급자는 소비자가 기능을 완전히 구현하기 전에도 소비자의 계약에 대해 테스트할 수 있습니다.
4. 계약 위반 조기 발견
계약을 위반하는 공급자 변경 사항은 개발 프로세스 초기에 감지되므로 개발자는 문제가 심각해지기 전에 해결할 수 있습니다.
소비자 중심 계약 테스트 구현 방법
CDCT를 구현하는 데 여러 가지 도구를 사용할 수 있으며 Pact가 가장 널리 사용되는 도구 중 하나입니다. Pact를 통해 소비자는 계약을 정의하고 공급자를 검증할 수 있습니다.
다음은 Pact를 사용하여 CDCT를 구현하는 단계별 가이드입니다.
1단계: 소비자 기대 정의
먼저 소비자 서비스에서 계약을 정의합니다. 여기에는 일반적으로 다음이 포함됩니다.
• 소비자가 호출할 엔드포인트.
• 요청 방식(GET, POST, PUT 등).
• 예상되는 요청 본문 또는 매개변수.
• 예상되는 응답 본문 및 상태 코드
다음은 JavaScript:
에서 Pact를 사용하여 소비자 테스트에서 계약을 정의하는 예입니다.
const { Pact } = require('@pact-foundation/pact'); const path = require('path'); const provider = new Pact({ consumer: 'UserService', provider: 'UserAPI', port: 1234, log: path.resolve(process.cwd(), 'logs', 'pact.log'), dir: path.resolve(process.cwd(), 'pacts'), }); describe('Pact Consumer Test', () => { beforeAll(() => provider.setup()); afterAll(() => provider.finalize()); it('should receive user details from the API', async () => { // Define the expected interaction await provider.addInteraction({ state: 'user exists', uponReceiving: 'a request for user details', withRequest: { method: 'GET', path: '/users/1', headers: { Accept: 'application/json', }, }, willRespondWith: { status: 200, headers: { 'Content-Type': 'application/json', }, body: { id: 1, name: 'John Doe', }, }, }); // Make the actual request and test const response = await getUserDetails(1); expect(response).toEqual({ id: 1, name: 'John Doe' }); }); });
이 예에서 소비자(UserService)는 /users/1에 GET 요청을 할 때 공급자(UserAPI)가 사용자 세부 정보를 반환할 것으로 기대합니다.
Step 2: Publish the Contract
Once the consumer test passes, Pact generates a contract file (Pact file) that can be shared with the provider. This contract can be stored in a Pact broker or a version control system so that the provider can use it for verification.
Step 3: Provider Verifies the Contract
The provider retrieves the contract and verifies that it complies with the consumer’s expectations. This is done by running a Pact test on the provider's side. Here’s an example of verifying a Pact contract in Java:
public class ProviderTest { @Test public void testProviderAgainstPact() { PactVerificationResult result = new PactVerifier() .verifyProvider("UserAPI", "pacts/UserService-UserAPI.json"); assertThat(result, instanceOf(PactVerificationResult.Ok.class)); } }
The provider runs this test to ensure that it adheres to the contract specified by the consumer.
Step 4: Continuous Integration
Once CDCT is integrated into your CI/CD pipeline, each time a contract changes, the provider can automatically verify the contract. This ensures that API changes do not break the consumer’s expectations, providing a safety net for both teams.
CDCT Best Practices
When to Use Consumer-Driven Contract Testing
CDCT is particularly useful when:
• You have microservices or distributed architectures with multiple services interacting.
• Teams working on different services need to develop independently without frequent integration testing.
• API contracts are likely to change often, and you want to avoid breaking consumer expectations.
• You need fast feedback loops to detect contract violations early in the development process.
Conclusion
Consumer-driven contract testing offers a reliable way to ensure that services in a distributed system communicate effectively without breaking changes. By focusing on consumer expectations and validating the provider against them, CDCT helps teams develop independently while ensuring stability. Whether you are building microservices, API-based applications, or distributed systems, incorporating CDCT into your testing strategy will improve the reliability and scalability of your services.
위 내용은 소비자 중심 계약 테스트 가이드의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!