계약 테스트

계약 테스트(Contract testing)는 두 서비스 간의 합의를 각각 격리된 상태에서 확인합니다. 양쪽은 실행 중인 상대 서비스가 아니라, 상호작용을 기술한 공유 문서인 계약(contract)을 기준으로 테스트됩니다. 제공자(provider)가 소비자(consumer)가 의존하는 필드 이름을 바꾸면, 아무것도 배포되기 전에 제공자 자신의 파이프라인에서 계약 테스트가 실패합니다. 비용과 신뢰도 면에서 통합 테스트와 E2E 테스트의 중간에 위치합니다.

소비자 주도 계약 테스트의 동작 방식

Pact 도구로 널리 알려진 가장 흔한 형태는 소비자 주도(consumer-driven) 방식입니다.

1. 소비자가 테스트를 작성합니다. 모의 제공자(mock provider)를 대상으로, 자신이 보내는 요청과 응답 중 실제로 사용하는 부분을 명시합니다. 예: GET /orders/42는 숫자 id와 문자열 status를 포함한 200을 반환한다.
2. 이 테스트를 실행하면 계약 파일(pact)이 생성됩니다. 해당 상호작용이 기록됩니다.
3. 계약을 공유합니다. 보통 브로커(broker) 서비스를 통해 공유합니다.
4. 제공자가 계약을 검증합니다. 기록된 요청을 실제 구현에 하나씩 재생하고 응답이 일치하는지 확인합니다.
5. 배포 전에 팀은 릴리스하려는 버전이 해당 환경에 이미 있는 상대편 버전들과 호환되는지 확인합니다.

소비자는 자신이 사용하는 필드만 명시하므로, 제공자는 필드를 추가하거나 어떤 소비자도 의존하지 않는 부분은 자유롭게 바꿀 수 있습니다.

관련 검사와의 차이

• 스키마 검증은 응답을 제공자가 공개한 스키마와 비교합니다. 제공자가 자신의 문서와 일관된다는 것은 알려 주지만, 각 소비자의 요구를 여전히 충족하는지는 알려 주지 않습니다.
• 통합 테스트는 실제 제공자를 호출합니다. 두 서비스와 그 의존성이 모두 실행 중이어야 하고, 더 느리고 불안정한 경향이 있습니다.
• E2E 테스트는 전체 흐름이 동작함을 증명하지만, 필드 이름이 바뀌었다는 사실을 알아내기에는 느리고 비싼 방법입니다.

제공자 주도 계약(provider-driven contract)은 제공자가 OpenAPI 명세를 공개하고 소비자가 그것을 기준으로 테스트하는 방식입니다. 공개 API처럼 제공자가 모든 소비자를 알거나 조율할 수 없을 때 대안이 됩니다.

흔한 실수

• 너무 많이 명시하기. 정확한 값이나 모든 필드를 어설션하면 계약이 깨지기 쉬운 기능 테스트가 됩니다. 타입 매처(matcher)를 쓰고 소비자가 읽는 부분만 포함하세요.
• 계약에서 비즈니스 로직 테스트하기. 계약은 대화의 형태를 확인하는 것이고, 정확성은 제공자 자신의 테스트에서 다뤄야 합니다.
• 제공자 상태(provider state) 생략하기. “주문 42가 존재한다”는 검증 중에 제공자 쪽에서 준비되어야 합니다. 그렇지 않으면 엉뚱한 이유로 검증이 실패합니다.