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

계약 테스트

계약 테스트는 소비자 테스트와 공급자 테스트로 구성됩니다. 소비자와 공급자 간의 간단한 예는 프론트엔드와 백엔드 간의 관계입니다. 프론트엔드가 소비자이고 백엔드가 공급자입니다. 프론트엔드는 백엔드에서 제공하는 API를 사용합니다. 이 테스트는 두 측이 합의된 계약을 준수하는지 확인하고, 계약에서의 어긋남이 있을 경우 중요한 대화를 유발하여 변경 사항이 누락되지 않도록 돕습니다.

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

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

spec/contracts/consumer/specs : 소비자 테스트
spec/contracts/provider/specs : 공급자 테스트

계약 자체는 현재 /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]              # 모든 병합 요청 계약 테스트 실행

Pact Broker에서 계약 확인

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

Pact Broker에 계약 게시

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

테스트 스위트 폴더 구조 및 명명 규칙

소비자 및 공급자 테스트 스위트를 구성하고 유지 관리하기 위해 테스트를 구성하고 소비자 및 공급자가 일관되게 명명되도록 하는 것이 중요합니다. 따라서 다음 규칙을 준수하는 것이 중요합니다.

테스트 스위트 폴더 구조

테스트 스위트에 조직적이고 합리적인 폴더 구조를 유지하면 리뷰, 디버깅 또는 테스트 도입 시 관련 파일을 쉽게 찾을 수 있습니다.

소비자 테스트

소비자 테스트는 응용프로그램의 다른 페이지에 따라 그룹화됩니다. 각 파일에는 페이지에 있는 다양한 유형의 요청이 포함되어 있습니다. 따라서 소비자 테스트 파일은 페이지 참조의 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 문서를 확인하여 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가 될 것입니다.

공급자가 문서화되지 않은 경우에도, 해당 API 요청 방법으로 시작하고 가능한 한 설명적인 이름으로 지정하여 어떤 공급자에 대한 것인지 쉽게 알 수 있도록 해야 합니다.

규칙 요약

테스트	폴더 구조	네이밍 규약
소비자 테스트	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`가 될 것입니다.