테스트 작성
- 소비자 테스트 실행
- 제공자 테스트 실행
  - Pact Broker에서 계약 확인
Pact Broker에 계약 게시
테스트 스위트 폴더 구조 및 네이밍 규칙
- 테스트 스위트 폴더 구조
  - 소비자 테스트
  - 제공자 테스트
- 네이밍 규칙

계약 테스트

계약 테스트는 소비자 테스트와 제공자 테스트로 구성됩니다. 소비자 및 제공자 간의 간단한 예는 프론트엔드와 백엔드 간의 관계입니다. 프론트엔드가 소비자이고 백엔드가 제공자입니다. 프론트엔드는 백엔드에서 제공하는 API를 사용합니다. 이 테스트는 두 측이 합의된 계약을 따르고 계약에서의 어긋남이 변경으로 이어지는 것을 막기 위해 의미 있는 대화를 유도하는 데 도움이 됩니다.

소비자 테스트는 각 spec이 요청 및 예상 mock 응답을 정의하고 이러한 정의를 기반으로 계약을 생성하는 유닛 테스트와 유사합니다. 반면에, 제공자 테스트는 계약에 정의된 요청을 가져와 해당 요청을 실제 서비스에 대해 실행한 후 계약과 일치시켜 계약을 유효성 검사하는 통합 테스트와 유사합니다.

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

spec/contracts/consumer/specs - 소비자 테스트.
spec/contracts/provider/specs - 제공자 테스트.

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

테스트 작성

소비자 테스트 실행

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

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

제공자 테스트 실행

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

$ bundle exec rake -T contracts
rake contracts:merge_requests:pact:verify:diffs_batch                                   # diffs_batch에 대한 소비자 요청에 대한 제공자 Pact 검증
rake contracts:merge_requests:pact:verify:diffs_metadata                                # diffs_metadata에 대한 소비자 요청에 대한 제공자 Pact 검증
rake contracts:merge_requests:pact:verify:discussions                                   # discussions에 대한 소비자 요청에 대한 제공자 Pact 검증
rake contracts:merge_requests:test:merge_requests[contract_merge_requests]              # 모든 병합 요청 계약 테스트 실행

Pact Broker에서 계약 확인

기본적으로 Rake 작업은 로컬에 저장된 계약을 확인합니다. Pact Broker에 게시된 계약을 확인하려면 PACT_BROKER 환경 변수를 true로 설정하고 QA_PACT_BROKER_HOST를 Pact Broker의 URL로 설정해야 합니다. 여기서 provider 테스트의 파일 경로 및 파일 이름을 통해 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/resources와 consumer/fixtures에서의 구조와 동일합니다.

폴더 이름의 명명은 레일스 명명 규칙에서 호출되는 방식과 일치하도록 복수형으로 지정되어야 합니다.

제공자 테스트

제공자 테스트는 우리의 컨트롤러와 유사하게 그룹화됩니다. 이러한 테스트는 각 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”와 같이 명명하지 않아야 합니다. 왜냐하면 GitLab 전체에서 사용자가 액세스할 수 있는 프로젝트 목록을 가져오는 GET /projects 엔드포인트도 있기 때문입니다.

적절한 이름을 선택하기 위해 API 문서를 확인하고 해당 이름이 문서에 있는 방식으로 작성하되 이름은 문장 케이스로 유지하도록 합니다. 따라서 GET /groups/:id/projects는 GET list a group's projects로 명명되며 테스트 파일명은 get_list_a_groups_projects_helper.rb가 됩니다. GET /projects는 GET list all projects로 명명되며 테스트 파일명은 get_list_all_projects_helper.rb가 됩니다.

제공자 테스트의 경우 일부 경우에는 테스트 대상인 제공자가 문서화되지 않을 수 있습니다. 이러한 경우에는 HTTP 요청 메서드로 시작하고 가능한 한 설명적인 이름을 사용하여 가장 명확하게 해당 제공자를 식별할 수 있도록 합니다.

규칙 요약

테스트	폴더 구조	명명 규칙
소비자 테스트	Rails 참조 표준을 따릅니다. 예를 들어 `Project::Pipelines#index`는 `consumer/specs/project/pipelines/index.spec.js`가 됩니다.	Rails 명명 표준을 따릅니다. 예를 들어 `Project::Pipelines#index`는 `project` 폴더 내부의 `Pipelines#index`가 됩니다.
제공자 테스트	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/pipelines`은 `GET list project pipelines`로 명명됩니다.