계약 테스트

계약 테스트는 소비자 테스트와 제공자 테스트의 두 부분으로 이루어져 있습니다. 소비자와 제공자 간의 간단한 예시는 프론트엔드와 백엔드입니다. 프론트엔드는 소비자가 되고, 백엔드는 제공자가 됩니다. 프론트엔드는 백엔드에서 제공하는 API를 사용합니다. 이 테스트는 두 측이 합의된 계약을 따르는지 확인하며, 계약에서 벗어나는 경우 의미 있는 대화를 촉발하여 파손 변경이 발생하지 않도록 합니다.

소비자 테스트는 각 사양이 요청 및 예상 모의 응답을 정의하고 이러한 정의를 기반으로 계약을 생성하는 점에서 단위 테스트와 유사합니다. 반면에 제공자 테스트는 각 사양이 계약에서 정의된 요청을 가져와 실제 서비스에서 해당 요청을 실행한 다음 계약과 비교하여 계약을 검증하는 점에서 통합 테스트와 유사합니다.

기존의 계약 테스트는 다음에서 확인할 수 있습니다:

계약 자체는 현재 /spec/contracts/contracts에 저장되어 있습니다. 계획은 AWS에 호스팅된 PactBroker 또는 유사한 서비스를 사용하는 것입니다.

테스트 작성하기

소비자 테스트 실행하기

소비자 테스트를 실행하기 전에 spec/contracts/consumer로 이동하여 npm install을 실행합니다. 모든 소비자 테스트를 실행하려면 npm run jest:contract -- /specs를 실행하면 됩니다. 그렇지 않으면 특정 사양 파일을 실행하려면 /specs를 특정 사양 파일 이름으로 바꾸면 됩니다. 소비자 테스트를 실행하면 제공자 테스트가 실제 API 동작을 검증하는 데 사용하는 계약이 생성됩니다.

또한 프로젝트의 루트 디렉터리에서 yarn jest:contract 명령을 사용하여 테스트를 실행할 수 있습니다.

제공자 테스트 실행하기

제공자 테스트를 실행하기 전에 GDK(GitLab Development Kit)가 완전히 설정되고 실행 중인지 확인하십시오. GDK 리포지토리에서 자세한 설치 지침을 따를 수 있습니다. 제공자 테스트를 실행하려면 ./lib/tasks/contracts에서 찾을 수 있는 Rake 작업을 사용합니다. 제공자 테스트와 관련된 모든 Rake 작업 목록을 얻으려면 bundle exec rake -T contracts를 실행하십시오. 예를 들면:

$ bundle exec rake -T contracts
rake contracts:merge_requests:pact:verify:diffs_batch                                   # 소비자 계약에 대해 제공자를 검증합니다. diffs_batch
rake contracts:merge_requests:pact:verify:diffs_metadata                                # 소비자 계약에 대해 제공자를 검증합니다. diffs_metadata
rake contracts:merge_requests:pact:verify:discussions                                   # 소비자 계약에 대해 제공자를 검증합니다. discussions
rake contracts:merge_requests:test:merge_requests[contract_merge_requests]              # 모든 merge request 계약 테스트 실행 

Pact Broker에서 계약 검증하기

기본적으로 Rake 작업은 로컬에 저장된 계약을 검증합니다. Pact Broker에 게시된 계약을 검증하려면 PACT_BROKER 환경 변수를 true로 설정하고 QA_PACT_BROKER_HOST를 Pact Broker의 URL로 설정해야 합니다. 여기서 중요한 점은 제공자 테스트의 파일 경로와 파일 이름이 Pact Broker에서 계약을 찾는 데 사용되기 때문에 제공자 테스트 명명 규칙을 준수하는 것이 중요합니다.

Pact Broker에 계약 게시하기

소비자 테스트에서 생성된 계약은 QA_PACT_BROKER_HOST 환경 변수를 설정하고 publish-contracts.sh 스크립트를 실행하여 호스팅된 Pact Broker에 게시할 수 있습니다.

테스트 스위트 폴더 구조 및 네이밍 규칙

소비자와 제공자 테스트 스위트를 정리하고 관리 가능하게 유지하기 위해, 테스트가 조직적이고 소비자와 제공자가 일관되게 이름 지어지는 것이 중요합니다. 따라서 다음 규칙을 준수하는 것이 중요합니다.

테스트 스위트 폴더 구조

테스트 스위트에 대한 조직적이고 합리적인 폴더 구조를 가지면, 리뷰, 디버깅 또는 테스트 도입 시 관련 파일을 찾기 쉬워집니다.

소비자 테스트

소비자 테스트는 애플리케이션의 다양한 페이지에 따라 그룹화됩니다. 각 파일에는 페이지에서 발견되는 다양한 유형의 요청이 포함되어 있습니다. 따라서 소비자 테스트 파일은 페이지가 참조되는 Rails 표준을 사용하여 이름이 지정됩니다. 예를 들어, 프로젝트 파이프라인 페이지는 Project::Pipelines#index 페이지가 되므로 해당 소비자 테스트는 consumer/specs/project/pipelines/index.spec.js에 위치하게 됩니다.

테스트에서 생성된 계약의 출력을 정의할 때, 우리는 동일한 파일 구조를 따르기를 원하며 이 예에서 contracts/project/pipelines/가 됩니다. 이는 consumer/resourcesconsumer/fixtures에서도 동일한 구조입니다.

폴더의 이름도 Rails 네이밍 표준에 맞춰 복수형으로 되어야 합니다.

제공자 테스트

제공자 테스트는 우리의 컨트롤러와 유사하게 그룹화됩니다. 각 테스트는 API 엔드포인트에 대한 다양한 테스트를 포함합니다. 예를 들어, 프로젝트에 대한 파이프라인 목록을 가져오는 API 엔드포인트는 provider/pact_helpers/project/pipelines/get_list_project_pipelines_helper.rb에 위치합니다. 제공자 상태는 소비자 테스트와 유사하게 애플리케이션의 다양한 페이지에 따라 그룹화됩니다.

네이밍 규칙

소비자와 제공자 테스트를 작성할 때, 소비자와 제공자에 대한 이름이 필요한 부분이 있습니다. Pact에서 이러한 이름이 어떻게 지정되어야 하는지에 대한 제한이 없기 때문에, 네이밍 규칙은 디버깅 시 어떤 소비자와 제공자 테스트가 관련되어 있는지 쉽게 파악할 수 있도록 하는 데 중요합니다. Pact는 또한 소비자 및 제공자 이름을 사용하여 #{consumer_name}-#{provider_name} 형식으로 로컬에 저장되는 계약 파일 이름을 생성합니다.

소비자 네이밍

폴더 구조 섹션에서 언급했듯이, 소비자 테스트는 애플리케이션의 다양한 페이지에 따라 그룹화됩니다. 따라서 소비자 이름은 Rails 표준을 사용한 동일한 네이밍 형식을 따라야 합니다. 예를 들어, Project::Pipelines#index의 소비자 테스트는 project 폴더 아래에 위치하며 소비자 이름은 Pipelines#index로 호출됩니다.

제공자 네이밍

이들은 소비자에게 데이터를 제공하는 API 엔드포인트이므로 해당 API 엔드포인트와 관련된 이름으로 지정됩니다. HTTP 요청 방법으로 시작하고 나머지 이름은 가능한 한 설명적이어야 합니다. 예를 들어, GET /groups/:id/projects 엔드포인트에 대한 테스트를 작성하고 있다면, “GET projects endpoint”라고 이름 짓지 않아야 합니다. 왜냐하면 GET /projects 엔드포인트도 있으며, 이 엔드포인트는 사용자가 GitLab 전역에서 액세스할 수 있는 프로젝트 목록을 가져오기 때문입니다.

적절한 이름을 선택하기 위해 API 문서를 확인하고 거기서 이름이 지정된 대로 이름을 지정하되, 문장 대문자를 유지하도록 합니다. 예를 들어 GET /groups/:id/projectsGET list a group's projects라고 이름 붙이며 테스트 파일 이름은 get_list_a_groups_projects_helper.rb입니다. GET /projectsGET list all projects라고 이름 붙이고 테스트 파일 이름은 get_list_all_projects_helper.rb입니다.

제공자가 테스트되는 경우에 문서화되지 않은 경우도 있으니, 그 경우에는 HTTP 요청 방법으로 시작하고 가능한 한 설명적인 이름을 사용하여 제공자가 무엇인지 쉽게 알 수 있도록 해야 합니다.

규약 요약

테스트 폴더 구조 명명 규약
Consumer Test Rails 참조 표준을 따릅니다. 예를 들어, Project::Pipelines#indexconsumer/specs/project/pipelines/index.spec.js가 됩니다. Rails 명명 표준을 따릅니다. 예를 들어, Project::Pipelines#indexproject 폴더 내에서 Pipelines#index가 됩니다.
Provider Test Rails 컨트롤러처럼 그룹화됩니다. 예를 들어, GET list project pipelines API 엔드포인트provider/pact_helpers/project/pipelines/provider/pact_helpers/project/pipelines/get_list_project_pipelines_helper.rb가 됩니다. 문장 대문자 형식의 API 문서 명명 방식을 따릅니다. 예를 들어, GET /projects/:id/pipelinesGET list project pipelines라고 불립니다.