Contract Testing

계약 테스트(Contract Testing)는 서비스 간 상호작용이 명시된 계약을 준수하는지 확인하는 테스트 방법론이다. 현대적인 소프트웨어 아키텍처, 특히 마이크로서비스 환경에서 매우 중요한 역할을 한다.

계약의 정의

API 계약은 서비스 제공자(Provider)와 소비자(Consumer) 간의 “약속"으로 볼 수 있다.

이 계약은 다음과 같은 요소를 포함한다:

API 엔드포인트 및 경로
요청 및 응답 형식(JSON, XML 등)
데이터 구조 및 필드 정의
상태 코드 및 오류 처리 방식
인증 및 권한 부여 요구사항

계약 테스트의 필요성

마이크로서비스 아키텍처에서는 수십, 수백 개의 서비스가 서로 상호작용한다.

이러한 환경에서 계약 테스트가 필요한 이유는 다음과 같다:

변경 관리: 서비스가 변경될 때 다른 서비스에 미치는 영향을 최소화
독립적 개발: 팀이 독립적으로 개발하면서도 통합 문제를 조기에 발견
빠른 피드백: 실제 통합 전에 문제를 식별하여 개발 주기 단축
신뢰성 향상: 시스템 전체의 안정성과 신뢰성 보장

계약 테스트 vs. 다른 테스트 방법

계약 테스트는 다른 테스트 방법과 어떻게 다른지 이해하는 것이 중요하다.

단위 테스트와의 차이점
- 단위 테스트: 개별 코드 단위의 기능을 검증
- 계약 테스트: 서비스 간 상호작용의 계약 준수 여부를 검증
통합 테스트와의 차이점
- 통합 테스트: 여러 컴포넌트를 실제로 연결하여 함께 작동하는지 검증
- 계약 테스트: 실제 통합 없이 계약 준수 여부만 검증
엔드투엔드 테스트와의 차이점
- 엔드투엔드 테스트: 전체 시스템을 통한 사용자 흐름 검증
- 계약 테스트: 서비스 간 경계에서의 상호작용만 검증

아래 표는 이러한 차이점을 요약한다:

특성	단위 테스트	통합 테스트	계약 테스트	엔드투엔드 테스트
테스트 대상	개별 함수/메소드	컴포넌트 간 상호작용	API 계약 준수 여부	전체 시스템 흐름
격리 수준	높음	중간	높음	낮음
실행 속도	매우 빠름	중간	빠름	느림
의존성 처리	모킹/스텁	일부 실제 의존성	계약 기반 목	실제 의존성
유지 관리 비용	낮음	중간	중간	높음
실제 환경 유사성	낮음	중간	중간	높음

계약 테스트의 종류

계약 테스트는 구현 관점에서 여러 유형으로 나눌 수 있다.

소비자 주도 계약 테스트 (Consumer-Driven Contract Testing)

소비자가 자신의 요구사항에 맞는 계약을 정의하고, 제공자가 이 계약을 준수하는지 확인한다.

특징:

소비자의 실제 요구사항에 기반
제공자는 모든 소비자의 계약을 충족해야 함
소비자의 요구사항 변화에 민감하게 대응 가능

예시 도구: Pact

제공자 주도 계약 테스트 (Provider-Driven Contract Testing)

제공자가 API 명세를 정의하고, 소비자가 이 명세에 맞게 개발하는지 확인한다.

특징:

제공자의 인터페이스 설계에 기반
소비자는 제공자의 명세를 따라야 함
명확한 API 문서화 가능

예시 도구: Swagger, OpenAPI

양방향 계약 테스트 (Bi-Directional Contract Testing)

최근에 등장한 접근 방식으로, 소비자와 제공자 양쪽의 관점을 모두 고려한다.

특징:

소비자와 제공자의 요구사항을 모두 반영
더 유연한 계약 정의 가능
구현이 복잡할 수 있음

예시 도구: Spring Cloud Contract

계약 테스트 구현 방법

계약 테스트를 구현하는 대표적인 방법을 살펴보자.

Pact를 이용한 소비자 주도 계약 테스트

Pact는 소비자 주도 계약 테스트를 위한 가장 인기 있는 도구.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// 소비자 측 테스트 예시 (JavaScript)
const { PactV3, MatchersV3 } = require('@pact-foundation/pact');
const { like } = MatchersV3;

const provider = new PactV3({
  consumer: 'OrderService',
  provider: 'ProductService'
});

describe('상품 API 계약 테스트', () => {
  it('상품 정보를 가져올 수 있어야 함', async () => {
    // 계약 정의
    await provider.addInteraction({
      states: [{ description: '상품 ID 10이 존재함' }],
      uponReceiving: '상품 정보 요청',
      withRequest: {
        method: 'GET',
        path: '/products/10'
      },
      willRespondWith: {
        status: 200,
        headers: { 'Content-Type': 'application/json' },
        body: like({
          id: 10,
          name: '스마트폰',
          price: 1000000,
          stock: 100
        })
      }
    });
    
    // 실제 API 호출 테스트
    const api = new ProductApi(provider.mockService.baseUrl);
    const product = await api.getProduct(10);
    
    expect(product.id).toBe(10);
    expect(product.name).toBe('스마트폰');
  });
});

위 예시에서 소비자(OrderService)는 제공자(ProductService)와의 상호작용 계약을 정의하고, 이 계약에 따라 테스트를 수행한다.

Spring Cloud Contract를 이용한 제공자 중심 계약 테스트

Spring Cloud Contract는 주로 Java 및 Spring 기반 애플리케이션에서 사용된다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
// 계약 정의 (Groovy DSL)
Contract.make {
    description "상품 정보 반환 계약"
    request {
        method GET()
        url "/products/10"
    }
    response {
        status 200
        headers {
            contentType applicationJson()
        }
        body([
            id: 10,
            name: "스마트폰",
            price: 1000000,
            stock: 100
        ])
    }
}

제공자는 이 계약을 기반으로 테스트를 실행하고, 계약에 따른 스텁을 생성하여 소비자에게 제공한다.

Swagger/OpenAPI를 이용한 스키마 기반 계약 테스트

OpenAPI 명세를 활용한 계약 테스트도 가능하다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# OpenAPI 명세
openapi: 3.0.0
info:
  title: 상품 API
  version: 1.0.0
paths:
  /products/{id}:
    get:
      summary: 상품 정보 조회
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: integer
      responses:
        '200':
          description: 상품 정보
          content:
            application/json:
              schema:
                type: object
                properties:
                  id:
                    type: integer
                  name:
                    type: string
                  price:
                    type: number
                  stock:
                    type: integer
                required:
                  - id
                  - name
                  - price

이 명세를 기반으로 openapi-validator와 같은 도구를 사용하여 API 응답이 스키마를 준수하는지 검증할 수 있다.

계약 테스트의 이점

계약 테스트를 도입함으로써 얻을 수 있는 구체적인 이점들을 살펴보자.

개발 생산성 향상
- 실제 통합 전에 문제를 발견하여 디버깅 시간 단축
- 독립적인 개발 및 배포 가능
- 병렬 개발 촉진
신뢰성 향상
- API 변경으로 인한 예상치 못한 장애 감소
- 서비스 간 호환성 보장
- 회귀 문제 조기 발견
문서화 개선
- 계약이 실행 가능한 API 문서 역할
- 항상 최신 상태 유지 (코드와 문서의 불일치 방지)
- 팀 간 커뮤니케이션 개선
비용 절감
- 통합 문제를 해결하는 데 필요한 시간과 노력 감소
- 실제 환경 설정 없이 테스트 가능
- 장애 복구 비용 감소

계약 테스트 구현 시 고려사항

계약 테스트를 효과적으로 구현하기 위한 주요 고려사항들.

버전 관리

계약 파일의 버전 관리 필요
이전 버전과의 호환성 고려
API 버전 관리 전략과 연계

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
project/
  ├── contracts/
  │   ├── v1/
  │   │   └── product-service.json
  │   └── v2/
  │       └── product-service.json
  └── tests/
      └── contract/
          ├── v1_test.js
          └── v2_test.js

CI/CD 통합

지속적 통합 파이프라인에 계약 테스트 포함
계약 위반 시 빌드 실패 처리
배포 전 계약 준수 확인

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
# 젠킨스 파이프라인 예시
pipeline {
  agent any
  stages {
    stage('계약 테스트') {
      steps {
        sh 'npm run test:contract'
      }
    }
    stage('배포') {
      when {
        expression { currentBuild.resultIsBetterOrEqualTo('SUCCESS') }
      }
      steps {
        sh 'npm run deploy'
      }
    }
  }
}

팀 협업 방식
- 소비자와 제공자 팀 간 커뮤니케이션 채널 확립
- 계약 변경 관리 프로세스 수립
- 계약 위반 시 알림 및 해결 프로세스
복잡한 시나리오 처리
- 상태 의존적인 상호작용 처리
- 비동기 API 호출 테스트
- 복잡한 데이터 구조 및 유효성 검사

실제 사례 연구

실제 기업들이 계약 테스트를 어떻게 활용했는지 살펴보면

넷플릭스의 계약 테스트 도입
넷플릭스는 수백 개의 마이크로서비스로 구성된 아키텍처를 가지고 있으며, 계약 테스트를 통해 서비스 간 호환성을 유지한다.
- Pact와 자체 개발한 도구를 조합하여 사용
- 소비자 주도 접근 방식 채택
- 발견된 문제: 초기 도입 시 팀 간 협업 방식 조정 필요
핀테크 기업의 계약 테스트 사례
결제 처리와 같은 중요한 기능을 제공하는 핀테크 기업에서는 API 안정성이 특히 중요하다.
- Spring Cloud Contract 활용
- 제공자 주도 접근 방식 선호
- 발견된 문제: 복잡한 결제 흐름을 계약으로 표현하는 어려움

계약 테스트의 한계 및 보완 방법

계약 테스트만으로는 해결할 수 없는 문제들이 있다.

한계점

비기능적 요구사항 검증 불가: 성능, 보안 등의 측면은 계약 테스트로 검증하기 어려움
복잡한 비즈니스 로직 검증 제한: 데이터 처리 로직의 정확성 검증에 한계
모든 시나리오 커버 불가: 예상치 못한 케이스나 극단적 상황 테스트 어려움
동적 응답 처리 어려움: 상황에 따라 다른 응답을 반환하는 API 테스트 복잡

보완 방법

다양한 테스트 조합: 단위 테스트, 통합 테스트, 엔드투엔드 테스트와 함께 사용
성능 테스트 별도 수행: 성능 요구사항은 별도의 성능 테스트로 검증
보안 테스트 추가: API 보안 취약점은 별도의 보안 테스트로 검증
카오스 엔지니어링: 예상치 못한 장애 상황에서의 시스템 동작 검증

Contract Testing