최신 마이크로서비스 아키텍처에서 애플리케이션은 종종 API를 통한 서비스 간 통신에 크게 의존합니다. 개발 중과 변경 후에도 이러한 API가 예상대로 계속 작동하는지 확인하는 것이 중요합니다. 이를 달성하는 효과적인 방법 중 하나는 소비자 중심 계약 테스트(CDCT)를 이용하는 것입니다. CDCT는 API를 사용하는 서비스(소비자)가 설정한 기대치를 서비스(생산자)가 준수하도록 보장하는 방법입니다.

이 가이드에서는 CDCT가 무엇인지, 어떻게 작동하는지, 안정적인 마이크로서비스 상호 작용을 보장하는 데 있어 CDCT의 중요성, Pact와 같은 도구를 사용하여 CDCT를 구현하는 방법을 살펴보겠습니다.

소비자 중심 계약 테스트란 무엇입니까?
소비자 중심 계약 테스트는 분산 아키텍처의 서비스 간 통신이 합의된 계약을 준수하는지 확인하는 테스트 전략입니다. API 자체가 올바르게 작동하는지 확인하는 것보다 소비자 요구에 초점을 맞춘다는 점에서 기존 API 테스트와 다릅니다. API 소비자와 공급자 간의 계약은 소비자의 기대에 따라 정의되며 이 계약은 공급자의 구현에 대해 검증됩니다.

주요 용어:
• 소비자: API를 소비하는 서비스입니다.
• Provider(Producer) : API를 제공하는 서비스이다.
• 계약: 예상되는 API 동작을 지정하는 소비자와 공급자 간의 공식 계약입니다.

어떻게 작동하나요?

1. 소비자가 계약을 정의합니다. 소비자는 공급자의 API가 어떻게 작동해야 하는지에 대한 기대치를 정의합니다(예: 예상하는 엔드포인트, 데이터 형식 및 응답 상태 코드).
2. 계약이 공유됩니다: 소비자는 이 계약을 공급자와 공유합니다. 이 계약은 공급자가 충족해야 하는 사항에 대한 사양 역할을 합니다.
3. 공급자가 계약을 확인합니다. 공급자는 소비자의 계약에 대해 스스로 테스트하여 소비자의 기대를 충족하는지 확인합니다.
4. 지속적인 피드백 루프: 공급자 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)가 사용자 세부 정보를 반환할 것으로 기대합니다.

2단계: 계약서 게시
소비자 테스트를 통과하면 Pact는 공급자와 공유할 수 있는 계약 파일(Pact 파일)을 생성합니다. 이 계약은 공급자가 검증에 사용할 수 있도록 Pact 브로커 또는 버전 관리 시스템에 저장될 수 있습니다.

3단계: 제공업체가 계약을 확인합니다.
공급자는 계약서를 검색하고 그것이 소비자의 기대를 준수하는지 확인합니다. 이는 공급자 측에서 Pact 테스트를 실행하여 수행됩니다. 다음은 Java로 Pact 계약을 확인하는 예입니다.

public class ProviderTest {

    @Test
    public void testProviderAgainstPact() {
        PactVerificationResult result = new PactVerifier()
            .verifyProvider("UserAPI", "pacts/UserService-UserAPI.json");

        assertThat(result, instanceOf(PactVerificationResult.Ok.class));
    }
}

공급자는 소비자가 지정한 계약을 준수하는지 확인하기 위해 이 테스트를 실행합니다.

4단계: 지속적인 통합
CDCT가 CI/CD 파이프라인에 통합되면 계약이 변경될 때마다 공급자는 자동으로 계약을 확인할 수 있습니다. 이렇게 하면 API 변경으로 인해 소비자의 기대가 깨지지 않고 두 팀 모두에게 안전망이 제공됩니다.

CDCT 모범 사례

1. 소규모, 집중 계약: 계약 규모가 작고 소비자의 요구에만 초점을 맞추도록 하세요. 이는 계약의 불필요한 복잡성을 방지하고 검증을 단순화합니다.
2. 계약 버전 관리: 항상 계약 버전을 관리하세요. 이를 통해 공급자는 동일한 계약의 여러 버전을 처리할 수 있으므로 다양한 개발 단계에서 다양한 소비자를 지원할 수 있습니다.
3. 독립 배포: CDCT가 CI/CD 파이프라인의 일부인지 확인하세요. 소비자 또는 공급자에 대한 변경 사항은 프로덕션 환경이 손상되지 않도록 계약 테스트를 트리거해야 합니다.
4. Pact 브로커 사용: Pact 브로커는 계약을 저장하고 소비자와 공급자 모두가 계약을 검색할 수 있도록 하는 중앙 저장소입니다. 또한 계약 버전 및 종속성을 시각화하기 위한 UI를 제공합니다.

소비자 중심 계약 테스트를 사용해야 하는 경우
CDCT는 다음과 같은 경우에 특히 유용합니다.
• 여러 서비스가 상호 작용하는 마이크로서비스 또는 분산 아키텍처가 있습니다.
• 다양한 서비스를 작업하는 팀은 빈번한 통합 테스트 없이 독립적으로 개발해야 합니다.
• API 계약은 자주 변경될 가능성이 높으며 소비자의 기대를 저버리지 않으려고 합니다.
• 개발 프로세스 초기에 계약 위반을 감지하려면 빠른 피드백 루프가 필요합니다.

결론
소비자 중심 계약 테스트는 분산 시스템의 서비스가 변경 사항을 중단하지 않고 효과적으로 통신하도록 보장하는 안정적인 방법을 제공합니다. CDCT는 소비자 기대에 초점을 맞추고 제공업체를 검증함으로써 팀이 안정성을 보장하면서 독립적으로 발전할 수 있도록 돕습니다. 마이크로서비스, API 기반 애플리케이션, 분산 시스템 등 무엇을 구축하든 CDCT를 테스트 전략에 통합하면 서비스의 안정성과 확장성이 향상됩니다.