계약 테스트
계약 테스트는 소비자 테스트(consumer tests)와 제공자 테스트(provider tests) 두 부분으로 구성됩니다. 소비자와 제공자 간의 간단한 예는 프론트엔드와 백엔드 사이의 관계입니다. 프론트엔드가 소비자이고 백엔드가 제공자입니다. 프론트엔드는 백엔드가 제공하는 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)가 완전히 설정되어 실행 중인지 확인하세요. 제공자 테스트를 실행하려면 제공자 테스트에 사용되는 레이크(rake) 작업을 사용하세요. 해당 레이크 작업은 ./lib/tasks/contracts
에서 찾을 수 있습니다. 제공자 테스트와 관련된 모든 레이크 작업의 디렉터리을 얻으려면 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에서 계약 확인
기본적으로 레이크 작업은 로컬에 저장된 계약을 확인합니다. 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에 게시할 수 있습니다.
테스트 스위트 폴더 구조 및 네이밍 규칙
소비자 및 제공자 테스트 스위트를 조직화하고 유지 관리하기 위해서는 테스트가 조직화되어 있고, 소비자 및 제공자가 일관되게 명명되는 것이 중요합니다. 따라서 다음 규칙을 준수하는 것이 중요합니다.
테스트 스위트 폴더 구조
테스트 스위트에 조직적이고 합리적인 폴더 구조가 있는 것은 리뷰, 디버깅 또는 테스트 도입 시 해당 파일을 쉽게 찾을 수 있도록합니다.
소비자 테스트
소비자 테스트는 응용 프로그램의 다른 페이지에 따라 그룹화됩니다. 각 파일에는 페이지에서 발견된 다양한 유형의 요청이 포함됩니다. 따라서 소비자 테스트 파일은 페이지 참조 방법에 따라 명명됩니다. 예를 들어, 프로젝트 파이프라인 페이지는 Project::Pipelines#index
페이지이므로 해당 소비자 테스트는 consumer/specs/project/pipelines/index.spec.js
에 위치합니다.
테스트에서 생성된 계약을 출력할 위치를 정의할 때, 동일한 파일 구조를 따르고 해당 예제의 경우 contracts/project/pipelines/
로 지정합니다. 이것은 consumer/resources
및 consumer/fixtures
의 구조입니다.
폴더의 명명은 레일스 명명 표준을 따르도록 복수형으로 지정되어야 합니다.
제공자 테스트
제공자 테스트는 우리의 컨트롤러와 유사하게 그룹화됩니다. 이러한 테스트 각각에는 프로젝트에 대한 다양한 테스트가 포함되어 있습니다. 예를 들어, 프로젝트의 파이프라인 디렉터리을 가져오는 API 엔드포인트는 provider/pact_helpers/project/pipelines/get_list_project_pipelines_helper.rb
에 위치합니다. 제공자 상태는 소비자 테스트와 유사하게 응용프로그램의 다른 페이지에 따라 그룹화됩니다.
네이밍 규칙
소비자 및 제공자 테스트를 작성할 때, 소비자 및 제공자의 이름이 필요한 부분이 있습니다. Pact에서는 이들 이름을 통해 #{consumer_name}-#{provider_name}
형식의 로컬 저장된 계약 파일 이름을 만듭니다.
소비자 이름 지정
폴더 구조 섹션에서 언급된대로 소비자 테스트는 응용 프로그램의 다른 페이지에 따라 그룹화됩니다. 따라서 소비자 이름은 레일스 표준을 사용하여 동일한 이름 형식을 따라야 합니다. 예를 들어, Project::Pipelines#index
의 소비자 테스트는 project
폴더에 위치하고 소비자 이름으로 Pipelines#index
로 지정됩니다.
제공자 이름 지정
이들은 소비자에게 데이터를 제공하는 API 엔드포인트이므로 해당 API 엔드포인트에 따라 명명됩니다. 문서화되지 않은 제공자가 테스트되는 경우, 가장 중요한 HTTP 요청 방법부터 시작하여 가능한 한 설명적인 이름으로 지정해야 합니다.
규칙 개요
테스트 | 폴더 구조 | 네이밍 규칙 |
---|---|---|
Consumer Test | Rails 참조 표준을 따릅니다. 예를 들어 Project::Pipelines#index 는 consumer/specs/project/pipelines/index.spec.js 가 됩니다.
| Rails 네이밍 표준을 따릅니다. 예를 들어 Project::Pipelines#index 는 project 폴더 내 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/pipelines 은 GET list project pipelines 로 불립니다.
|