introduction contract testing with examples
이 Pact 계약 테스트 자습서에서는 소비자 주도 계약 테스트가 무엇인지, 어떻게 작동하며 테스트 전략에서 사용해야하는 이유를 설명합니다.
계약 테스트 란 무엇입니까?
소비자 주도 계약 테스트는 진정으로 좌회전을 가능하게하는 API 테스트의 한 형태입니다. 우리가 사용하는 계약 도구는 Pact.io ,이 튜토리얼 시리즈의 뒷부분에서 이에 대해 알아볼 것입니다.
계약 테스트는 통과 된 내용을 테스트하고 반환 된 내용이 '계약'과 일치하는지 확인하기 위해 두 응용 프로그램 간의 통합을 독립적으로 확인하는 방법입니다.
계약 테스트는 민첩한 설정에서 작동하는 마이크로 서비스 아키텍처에 잘 맞습니다. 따라서 예제는이 환경에서 작업하면서 얻은 경험을 기반으로합니다.
학습 내용 :
이 계약 테스트 시리즈의 자습서 목록
튜토리얼 # 1 : 예제를 통한 계약 테스트 소개 [이 튜토리얼]
튜토리얼 # 2 : JavaScript에서 Consumer Pact 테스트를 작성하는 방법
튜토리얼 # 3 : Pact 브로커에게 Pact 계약을 게시하는 방법
튜토리얼 # 4 : Pact CLI로 Pact 계약 및 지속적 배포 확인
소비자 주도 계약 테스트
시작점은 테스트 계약을 형성하는 API 문서입니다.이 시점에서 일반적으로 개발 팀은 API 문서를 가져와 위키 문서 (또는 Word 문서와 같이 조직에있는 형식)에 대해 개발합니다.
예를 들면 프론트 엔드는 Team Krypton에서 개발하고 API는 Team Thoron에서 개발중인 웹 애플리케이션입니다. 프로젝트는 요구 사항이 제시되고 팀간에 합의되는 시작 회의로 시작됩니다.
각 팀은 요구 사항을 받아들이고 스토리를 구체화하여 백 로그를 만들기 시작합니다. 개발은 사용자 스토리에 따라 두 팀에서 시작되며 통합 테스트는 나중에 스프린트를 위해 남겨집니다. Team Krypton이 오류 시나리오와 관련된 추가 요구 사항을 찾으면 이에 따라 API 문서가 업데이트됩니다.
테스트 케이스는 문서를 기반으로 업데이트 된 시나리오와 관련하여 Team Thoron에 의해 추가됩니다.
이미이 프로세스에서 몇 가지 결함을 볼 수 있으며 행운을 위해 몇 가지를 더 추가했습니다.
- API 문서 변경 사항은 효과적으로 전달되지 않을 수 있습니다.
- 프런트 엔드 팀은 백 엔드 서비스를 스텁하고 그 반대의 경우도 마찬가지입니다.
- 백엔드 팀은 문서를 기반으로 통합 테스트 케이스를 생성합니다.
- 통합 환경은 전체 통합이 테스트되는 첫 번째입니다.
- 통합 환경과 프로덕션의 API 버전이 다릅니다.
소비자 중심의 계약 테스트에는 소비자와 공급자라는 두 가지 측면이 있습니다. 여기에서 마이크로 서비스 테스트에 대한 기존의 생각이 뒤집혀 있습니다.
그만큼 소비자 요청 및 예상 응답을 포함하는 시나리오의 큐레이터입니다. 이것은 당신이 따를 수 있습니다 베드의 법칙 이는 API가 수용 할 수있는 것은 유연해야하지만 전송되는 것은 보수적이어야 함을 나타냅니다. 결함을 다시 언급합니다. 1, 3 및 4에서 문서 변경은 소비자가 주도합니다.
예를 들면 Team Thoron이 null 값을 허용하지 않도록 문자열 필드를 변경하는 상황에서 소비자 테스트는 변경 사항을 반영하지 않으므로 실패합니다. 또는 적어도 Team Krypton이 변경 될 때까지.
[영상 출처 ]
그만큼 공급자 소비자가 제공 한 시나리오를 '개발'환경에 대해 확인합니다. 이를 통해 마이크로 서비스가 병렬 변경 API 기능을 확장 한 다음 새 버전으로 마이그레이션해야 함을 나타냅니다. 결함 번호를 다시 참조하십시오. 2, 일반적으로 백엔드 팀에서 자체 테스트 요구 사항을 위해 만든 스텁은 이제 다음을 사용하는 소비자 시나리오를 기반으로 할 수 있습니다. 팩트 스텁 서버 .
양측의 구속력있는 요소는 팀간에 공유해야하는 '계약'입니다. 이 협약은 계약을 공유 할 수있는 플랫폼을 제공합니다. 협정 중개인 (관리 형 서비스로 사용 가능 Pactflow.io ).
그만큼 브로커 소비자 시나리오의 출력을 저장합니다. 그런 다음 계약은 API 버전과 함께 브로커 내에 저장됩니다. 이를 통해 여러 버전의 API에 대해 테스트 할 수 있으므로 결함 5에서 강조 표시된대로 릴리스 전에 호환성을 확인할 수 있습니다.
레거시 플랫폼에서 Pact Broker의 추가 이점은 소비자의 가시성입니다. 모든 소비자가 API 작성자에게 알려진 것은 아니며, 특히 소비되는 방식이 아닙니다.
특히 두 개의 API 버전이 지원되는 발생을 언급하면 버전 1 (V1) 내에 데이터 문제가있어 API가 더티 데이터 데이터베이스에서.
변경 사항은 API V1에서 구현되어 프로덕션으로 푸시되었지만 소비자는 데이터 문제를 일으키는 형식에 의존하여 API와의 통합을 깨뜨 렸습니다.
작동 원리
위의 예는 인증 흐름을 보여줍니다. 웹 서비스에서는 사용자가 민감한 데이터에 액세스하기 위해 인증해야합니다. 웹 서비스는 사용자 이름과 암호를 사용하여 토큰을 생성하도록 API에 요청을 보냅니다. API는 데이터 요청에 인증 헤더로 추가되는 전달자 토큰을 반환합니다.
소비자 테스트는 사용자 이름과 암호로 본문을 전달하여 토큰에 대한 POST 요청을 구성합니다.
모의 서버는이 예제에서 토큰 값을 포함하는 예상 응답과 함께 생성 한 요청의 유효성을 검사하는 테스트 중에 회전됩니다.
소비자 테스트의 출력은 pact 계약 파일을 생성합니다. 이것은 pact 브로커에 버전 1로 저장됩니다.
그런 다음 공급자는 pact 브로커에서 버전 1을 가져와 요청 및 응답이 소비자 요구 사항과 일치하는지 확인하여 로컬 환경에 대해이 요청을 재생합니다.
역할과 책임
품질 보증 (QA) / 테스터 : Pact.io를 사용하여 계약을 작성하고 BA와 협력하여 테스트 시나리오를 생성합니다.
개발자: 테스트를 만들고 CI (지속적 통합)에서 구현하기위한 API 래핑에 대해 QA와 페어링합니다.
비즈니스 분석가 (BA) : 시나리오를 생성하고 설계자와 협력하여 영향을받는 당사자를 확인합니다.
솔루션 설계자 (귀하의 조직에 존재하지 않을 수 있음) : API 변경에 대한 조치를 취하고 구현시 BA와 조정하며 변경 사항을 소비자에게 전달합니다 (Pact Broker를 사용하여 우려 할 수있는 사람을 이해).
릴리스 관리 : (예, 구식이지만 여전히 내 세상에 존재합니다.) : 계약 테스트 범위로 인해 변경 사항이 성공적으로 출시 될 것이라는 확신으로 가득 차 있습니다.
전체 팀 : 결과를 확인하여 Pact CLI 도구를 사용하여 릴리스를 프로덕션으로 푸시 할 수 있는지 확인합니다. 배포 할 수 있습니까? .
계약 테스트 대 통합 테스트
프로덕션 환경으로 승격하기 전에 시스템이 작동하는지 확인하려면 통합 테스트가 있어야하지만 시나리오를 크게 줄일 수 있습니다.
이로 인한 영향은 다음과 같습니다.
- 통합 환경으로 출시하기 전에 더 빠른 피드백.
- 통합 환경의 안정성에 덜 의존합니다.
- 여러 API 버전을 지원하는 더 적은 환경.
- 통합 문제로 인한 불안정한 환경 인스턴스 감소.
| 완성 | 계약 | |
|---|---|---|
| 분명한 오류 파악 | 많은 층 | 아주 쉽게 |
| API 구성 | 예 | 하지 마라 |
| 배포 확인 | 예 | 하지 마라 |
| API 버전 관리 | 예 | 예 |
| 로컬 디버그 | 하지 마라 | 예 |
| 환경 문제 | 예 | 하지 마라 |
| 피드백 시간 | 느린 | 빠른 |
첫째, 계약 테스트는 통합 테스트를 대체하지 않습니다. 그러나 기존 통합 테스트 시나리오 중 일부를 대체하고 왼쪽으로 이동하며 소프트웨어 개발 수명주기에 더 빠른 피드백을 제공 할 수 있습니다.
통합 테스트에서는 환경 아키텍처, 배포 프로세스 등과 같이 API가 존재하는 컨텍스트를 확인합니다.
따라서 구성을 확인하는 핵심 테스트 시나리오를 실행하고 싶습니다. 예를 들면 api 버전에 대한 상태 확인 엔드 포인트. 또한 200 응답을 반환하여 배포 성공 여부를 증명합니다.
계약 테스트에서는 API 구조, 콘텐츠 (예 : 필드 값, 키 존재) 및 오류 응답과 관련된 엣지 케이스를 포함하는 API의 세부 사항을 테스트합니다. 예를 들면 API가 null 값을 처리하거나 API 응답에서 제거됩니까 (또 다른 실제 예).
일부 혜택 (아직 판매하지 않은 경우)
계약 테스트를 더 광범위한 비즈니스에 판매하는 동안 얻을 수있는 몇 가지 이점은 다음과 같습니다.
- 더 빠른 소프트웨어 배포
- 단일 진실 소스
- 모든 소비자의 가시성
- 다양한 API 버전에 대한 테스트 용이성.
자주 묻는 질문
사람들이 계약 테스트를 채택하도록 설득하는 동안 일반적인 질문은 다음과 같습니다.
Q # 1) 이미 100 % 테스트 커버리지가 있으므로 필요하지 않습니다.
대답: 불가능하지만 계약 테스트에는 테스트 적용 범위 외에 많은 다른 이점이 있습니다.
Q # 2) API 변경 사항을 알리는 것은 솔루션 아키텍트의 책임입니다.
대답: 품질은 전체 팀의 책임입니다.
Q # 3) API 팀을위한 테스트 시나리오를 만드는 이유는 무엇입니까?
대답: API 팀은 웹 서비스가 어떻게 작동하는지 모르기 때문에 왜 책임이 있어야합니다.
Q # 4) 우리의 종단 간 테스트는 다른 통합 지점을 포함하여 처음부터 끝까지 전체 흐름을 다룹니다.
대답: 정확히 한 가지 테스트를 위해 테스트를 분할하는 이유이며 작동 방식을 모르는 시스템의 종단 간 흐름을 테스트하는 것은 사용자의 책임이 아닙니다.
Q # 5) 테스트는 어느 팀의 저장소에 있습니까?
대답: 양자 모두. 자신의 저장소에있는 소비자와 그들의 저장소에있는 공급자. 그런 다음 중앙 지점에서 계약은 둘 중 하나의 외부에 있습니다.
내 네트워크 보안 키는 어디에 있습니까
인수
다음은 테스트 계약으로 전환 할 때 반대하기 어려운 주장입니다.
- 통합 테스트를 생성하는 데 사용할 수있는 Swagger 문서가 이미 있습니다.
- 팀은 API 변경을위한 효과적인 메커니즘을 사용하여 프런트 엔드 및 백 엔드 서비스를 모두 소유합니다.
지속적인 통합
이것이 지속적 통합 테스트 스위트에 어떻게 적합합니까? 계약 테스트를하기에 바람직한 장소는 단위 테스트입니다.
소비자 테스트는 테스트 외부의 외부 종속성이 필요하지 않은 모의 서버를 가동합니다.
공급자 테스트에는 API 인스턴스가 필요하므로 로컬 API는 인 메모리 테스트 서버 . 그러나 API를 로컬로 래핑하는 것이 쉽지 않은 경우 이전에 사용한 해결 방법은 환경을 스핀 업하고 풀 요청 자동화 검사의 일부로이 환경에 코드를 배포하는 것입니다.
[영상 출처 ]
결론
이 자습서에서는 계약 테스트의 의미와 마이크로 서비스 인프라에서 어떻게 보이는지 배웠고 실제 예제에서 어떻게 보이는지 살펴 보았습니다.
계약 테스트가 통합 테스트를 왼쪽으로 이동하는 데 어떻게 도움이되는지에 대한 교훈을 얻었습니다. 또한 통합 문제와 관련된 피드백 시간을 줄여 조직의 비용을 절감 할 수있는 방법을 확인했습니다.
계약 테스트는 기술 테스트를위한 도구 일뿐만 아니라 변경 사항을 전달하고 테스트를 하나의 단위로 장려하여 개발 팀의 협업을 강화합니다. 전반적으로 이는 지속적 배포로 전환하려는 모든 사람에게 전제 조건이어야합니다.
NEXT 튜토리얼
추천 도서
- JavaScript에서 Consumer Pact 테스트를 작성하는 방법
- Pact CLI로 Pact 계약 및 지속적 배포 확인
- Pact 브로커에게 Pact 계약을 게시하는 방법
- 지속적인 통합 프로세스 : 소프트웨어 품질을 개선하고 위험을 줄이는 방법
- 단위 테스트, 통합 테스트 및 기능 테스트의 차이점
- 통합 테스트 란 무엇입니까 (통합 테스트 예제가 포함 된 자습서)
- 통합 테스트 작성을위한 상위 10 가지 통합 테스트 도구
- DevOps의 지속적인 배포