계약 테스트

계약 테스트는 소비자 테스트와 제공자 테스트로 구성됩니다. 소비자 및 제공자 간의 간단한 예는 프론트엔드와 백엔드 간의 관계입니다. 프론트엔드는 소비자이고 백엔드는 제공자입니다. 프론트엔드는 백엔드에서 제공되는 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 리포지터리의 설정 지침을 따를 수 있습니다. 제공자 테스트를 실행하려면 제공자 테스트에 관련된 Rake tasks를 사용합니다. 해당 작업은./lib/tasks/contracts에서 찾을 수 있습니다. 제공자 테스트와 관련된 모든 Rake tasks 디렉터리을 얻으려면 bundle exec rake -T contracts를 실행하세요. 예: 

$ bundle exec rake -T contracts
rake contracts:merge_requests:pact:verify:diffs_batch                                   # diffs_batch에 대한 소비자 pacts를 제공자가 확인
rake contracts:merge_requests:pact:verify:diffs_metadata                                # diffs_metadata에 대한 소비자 pacts를 제공자가 확인
rake contracts:merge_requests:pact:verify:discussions                                   # discussions에 대한 소비자 pacts를 제공자가 확인
rake contracts:merge_requests:test:merge_requests[contract_merge_requests]              # 모든 Merge Request 계약 테스트 실행

Pact Broker에서 계약 확인

기본적으로 Rake task는 로컬에 저장된 계약을 확인합니다. 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/입니다. 여기서도 폴더 이름은 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”로 이름을 짓지 않으려고 합니다. 왜냐하면 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로 불립니다.