애저 파이프라인 자동화 API 테스트 단계별 가이드

API는 노트북에서 잘 작동합니다. 로컬 테스트 클라이언트에서 모든 검사를 통과합니다. 그러다 팀원이 브랜치를 병합하고 배포가 진행되면, 이전에는 200을 반환하던 엔드포인트가 프로덕션에서 500을 반환하기 시작합니다. 아무도 이를 잡지 못했습니다. 왜냐하면 아무도 해당 브랜치에서 테스트를 실행하지 않았기 때문입니다. 그들은 한 번, 수동으로 한 컴퓨터에서만 테스트를 실행했습니다.

“테스트가 존재한다”와 “모든 변경 사항에 대해 테스트가 실행된다” 사이의 간극을 정확히 CI 파이프라인이 메워줍니다. 코드가 이미 Azure Repos 또는 GitHub에 있고 팀이 Azure DevOps에서 빌드하는 경우, Azure Pipelines는 이러한 안전망을 구축하기에 자연스러운 곳입니다. 어려운 부분은 YAML이 아닙니다. 파이프라인이 올바른 환경에서 새로 배포된 빌드를 대상으로 헤드리스 방식으로 실행할 수 있는 형태로 API 테스트 스위트를 구성하고, 문제가 발생하면 빌드를 크게 실패시키는 것입니다.

버튼

요약 (TL;DR)

Azure Pipelines는 모든 커밋 또는 PR에서 API 테스트를 자동으로 실행하여, 회귀가 배포되기 전에 발견될 수 있도록 합니다.
Apidog에서 시각적으로 테스트 시나리오를 구축한 다음, 수동으로 테스트 스크립트를 작성하고 유지 관리하는 대신 Apidog CLI (apidog-cli)를 사용하여 CI에서 실행하십시오.
파이프라인에는 네 가지가 필요합니다: 에이전트에 Node.js 설치, CLI 설치, 링크 또는 내보낸 파일을 통해 접근 가능한 테스트 시나리오, 그리고 시크릿으로 저장된 액세스 토큰.
CLI에서 0이 아닌 종료 코드가 반환되면 빌드가 자동으로 실패합니다. 이것이 진정한 게이트를 제공합니다.
HTML 또는 JUnit 보고서를 파이프라인 아티팩트로 게시하여 (PublishTestResults를 통해서도 가능) 누구든지 로그를 열지 않고도 합격/불합격 여부를 읽을 수 있도록 하십시오.

“Azure Pipelines에서 자동화된 API 테스트”가 실제로 의미하는 것

Azure Pipelines는 Azure DevOps 내의 CI/CD 서비스입니다. 리포지토리에 있는 YAML 파일(azure-pipelines.yml)에 빌드를 정의하면, 트리거(푸시, 풀 리퀘스트, 스케줄 또는 수동 실행)가 발생할 때마다 Azure가 호스팅되거나 자체 호스팅된 에이전트에서 해당 파일을 실행합니다.

API 테스트의 경우, 작업은 간단한 형태를 가집니다:

에이전트(클린 VM)를 시작합니다.
테스트 러너에 필요한 모든 것을 설치합니다.
대상 환경에 대해 API 테스트를 실행합니다.
결과를 보고하고, 그에 따라 빌드 상태를 설정합니다.

사람들이 헷갈리는 부분은 3단계입니다. 로컬 API 클라이언트는 상호작용적입니다. "보내기"를 클릭하고, 응답을 눈으로 확인하고, 녹색 체크 표시를 읽습니다. 파이프라인에는 클릭할 사람도, 눈으로 확인할 사람도 없습니다. 사람의 개입 없이, GUI 없이 동일한 단언(assertions)을 실행할 방법이 필요합니다. 이것이 바로 명령줄 러너가 존재하는 이유입니다.

여기서 CI 개념에 대한 더 넓은 입문서가 필요하다면, 첫 파이프라인을 연결하기 전에 지속적 통합, 지속적 전달, 지속적 배포의 차이점을 빠르게 읽어보는 것이 좋습니다.

Apidog에서 테스트를 설계하고 CLI로 실행하는 이유

원시 코드로 API 테스트를 작성할 수도 있습니다. 언어를 선택하고, HTTP 라이브러리와 단언(assertion) 프레임워크를 가져오고, 요청 본문을 수동으로 작성하고, 응답을 파싱하고, 인증 토큰을 관리하고, 매 스프린트마다 변경되는 API와 모든 것을 동기화해야 합니다. 팀들은 이렇게 합니다. 그리고 유지 관리에 불균형적으로 많은 시간을 보냅니다.

Apidog는 다른 경로를 택합니다. 테스트 시나리오를 시각적으로 구축합니다: 요청을 연결하고, 한 응답의 데이터를 다음 요청으로 전달하고, 상태 코드, 헤더 및 JSON 필드에 단언(assertion)을 추가하고, 여러 데이터 행으로 동일한 시나리오를 실행합니다. Apidog가 이미 API 정의를 가지고 있기 때문에 테스트는 사양과 가깝게 유지됩니다. 스키마가 변경되면, 프로덕션에서 발견하는 대신 차이점을 보게 됩니다.

이 시각적 작업을 CI에 연결하는 부분은 npm에 게시된 명령줄 러너인 Apidog CLI입니다. 이는 저장된 테스트 시나리오를 헤드리스 방식으로 실행하고, 결과에 따라 상태 코드를 반환하며 종료됩니다: 모든 것이 통과하면 0, 어떤 단언(assertion)이라도 실패하면 0이 아닌 값. 이 종료 코드는 모든 CI 시스템이 이해하는 계약입니다. Azure Pipelines는 이를 읽고 빌드가 성공(녹색)인지 실패(빨간색)인지 결정합니다. GUI에서 한 번 설계하면, 동일한 시나리오가 파이프라인에서 변경 없이 실행됩니다.

이는 GitHub Actions, GitLab CI, Jenkins에서도 작동하는 동일한 모델입니다. Azure Pipelines는 동일한 CLI 명령을 위한 또 다른 호스트일 뿐이며, 이는 팀이 플랫폼을 전환하더라도 지식이 이전된다는 것을 의미합니다.

사전 준비 사항

파이프라인을 구축하기 전에 다음 사항을 준비하십시오:

하나 이상의 테스트 시나리오가 있는 Apidog 프로젝트. 테스트 시나리오 섹션을 열고, 시나리오를 생성하고, 몇 가지 요청을 추가하고, 단언(assertion)을 연결하십시오. 로컬에서 한 번 실행하여 통과하는지 확인하십시오. 로컬에서 불안정하면 CI에서도 불안정할 것입니다.
Apidog 액세스 토큰. CLI는 Apidog 계정 설정에서 개인 액세스 토큰으로 인증합니다. 이를 비밀번호처럼 취급하십시오. YAML에 절대 저장하지 않고, 파이프라인 시크릿으로 저장할 것입니다.
리포지토리가 있는 Azure DevOps 프로젝트. azure-pipelines.yml 파일은 리포지토리 루트에 위치합니다.
Node.js 지식(가볍게). CLI는 Node에서 실행되므로 에이전트에 Node가 설치되어 있어야 합니다. Azure의 호스팅된 에이전트에는 이미 Node가 있으므로 버전을 선택하기만 하면 됩니다.
접근 가능한 대상 환경. 테스트는 실행 중인 API를 호출해야 합니다. 스테이징 URL, 미리보기 배포 또는 파이프라인 자체가 시작하는 서비스여야 합니다. 트리거를 작성하기 전에 어떤 것을 사용할지 결정하십시오.

어떤 대상을 테스트할지에 대한 간략한 참고사항입니다. 모든 커밋에서 프로덕션을 대상으로 스위트를 실행하는 것은 위험하고 종종 불가능합니다(프로덕션에 테스트 데이터를 원하지 않을 것입니다). 대부분의 팀은 CI 테스트를 스테이징 환경 또는 브랜치별 미리보기 배포로 지정합니다. Apidog 환경은 이를 깔끔하게 만듭니다: 자체 기본 URL과 변수를 가진 Staging 환경을 유지하고, CLI에 런타임에 어떤 환경을 사용할지 알려주십시오.

1단계: 테스트 시나리오를 실행 가능한 형태로 만들기

CLI는 어떤 시나리오를 실행해야 하는지 알아야 합니다. Apidog는 두 가지 방법으로 이를 제공합니다.

옵션 A: 공유 온라인 링크에서 실행. Apidog에서 테스트 시나리오를 열고 CLI를 통해 실행하도록 선택하면, Apidog는 네트워크를 통해 시나리오를 가리키는 명령을 생성합니다. 이것은 유지 관리가 적은 옵션입니다: 파이프라인은 항상 시나리오의 현재 버전을 실행하며, 테스트 파일을 리포지토리에 커밋하지 않습니다. 단점은 파이프라인이 런타임에 해당 링크에 접근 가능해야 한다는 점입니다.

옵션 B: 시나리오를 파일로 내보내고 커밋. 시나리오(및 해당 환경)를 로컬 파일로 내보내고, 코드와 함께 커밋한 다음, CLI가 파일 경로를 가리키도록 합니다. 이는 테스트를 특정 커밋에 고정시키며, 재현성을 중요하게 생각한다면 원하는 방식입니다. 실행된 테스트는 해당 커밋의 테스트와 정확히 일치합니다. 단점은 시나리오가 변경될 때마다 다시 내보내야 한다는 점입니다.

대부분의 초보 팀에게는 옵션 A가 더 빠르게 연결됩니다. 규제 또는 감사 중심 작업의 경우 옵션 B의 재현성이 더 유리합니다. 빠르게 변경되는 기능 브랜치에는 링크 기반을, 릴리스 브랜치에는 파일 기반을 사용하는 등 혼합하여 사용할 수도 있습니다.

어떤 방법을 사용하든, Apidog가 제공하는 정확한 실행 명령을 기록해 두십시오. 다음과 유사할 것입니다:

apidog run https://api.apidog.com/api/v1/test-scenarios/<scenario-id> \
 -t <access-token> \
 -e <environment-id>

가장 많이 사용할 플래그:

시나리오 참조(온라인 링크 또는 로컬 파일 경로),
인증을 위한 -t / 액세스 토큰,
실행할 환경을 위한 -e,
출력 형식을 제어하는 리포터 옵션(CLI 텍스트, HTML 또는 기계가 읽을 수 있는 요약),
데이터 세트를 반복하려는 경우의 반복 횟수.

Apidog가 시나리오에 대해 생성하는 실행 명령과 정확한 플래그 이름을 확인하십시오. 러너는 apidog run --help를 통해 사용법을 출력합니다. 플래그를 추측하지 마십시오. Apidog가 제공하는 것을 복사하고 시크릿을 매개변수화하십시오.

2단계: CLI가 로컬에서 먼저 작동하는지 확인

CI 내에서 새로운 도구를 디버깅하지 마십시오. 파이프라인 피드백 루프는 느리고 로그는 터미널보다 시끄럽습니다. 먼저 자신의 머신에서 성공적인 실행을 확인하십시오.

CLI 설치:

npm install -g apidog-cli

그런 다음 시나리오를 실행하십시오:

apidog run https://api.apidog.com/api/v1/test-scenarios/<scenario-id> \
 -t "$APIDOG_ACCESS_TOKEN" \
 -e "<staging-environment-id>"

세 가지를 확인해야 합니다:

명령이 완료되고 합격/불합격 요약을 출력합니다.
종료 코드가 결과와 일치합니다. 바로 뒤에 echo $?를 실행하십시오. 성공 시 0이어야 하고, 실패 시 0이 아닌 값이어야 합니다.
환경이 올바르게 해결되었습니다. 요청은 스테이징 URL을 호출하며, 남아 있는 로컬 URL을 호출하지 않습니다.

그 종료 코드 확인은 보이는 것보다 중요합니다. 단언(assertion)이 실패했음에도 CLI가 0으로 종료된다면, 파이프라인은 깨진 코드에도 불구하고 성공으로 표시될 것이며, 이는 테스트가 전혀 없는 것보다 더 나쁩니다. 한 번 의도적으로 실패를 유도하여 (일부러 단언을 깨뜨려) 0이 아닌 코드를 받는지 확인하십시오. 그런 다음 단언을 다시 복구하십시오.

3단계: Azure Pipelines YAML 생성

리포지토리 루트에 azure-pipelines.yml이라는 파일을 추가하십시오. 호스팅된 Ubuntu 에이전트를 위한 완전하고 작동하는 시작점은 다음과 같습니다:

trigger:
 branches:
 include:
 - main
 - develop

pr:
 branches:
 include:
 - main

pool:
 vmImage: ubuntu-latest

variables:
 NODE_VERSION: '20.x'

steps:
 - task: NodeTool@0
 inputs:
 versionSpec: $(NODE_VERSION)
 displayName: 'Install Node.js'

 - script: npm install -g apidog-cli
 displayName: 'Install Apidog CLI'

 - script: |
 apidog run https://api.apidog.com/api/v1/test-scenarios/$(SCENARIO_ID) \
 -t $(APIDOG_ACCESS_TOKEN) \
 -e $(STAGING_ENV_ID)
 displayName: 'Run API tests'

단계별 설명:

trigger는 main 및 develop 브랜치에 대한 모든 푸시에서 파이프라인을 실행합니다. 브랜치 이름에 맞게 조정하십시오.
pr은 main을 대상으로 하는 풀 리퀘스트에서 실행됩니다. 이는 깨진 브랜치가 병합되는 것을 막는 게이트입니다.
pool / vmImage는 Microsoft에서 호스팅하는 Ubuntu 에이전트를 선택합니다. 관리할 인프라가 없습니다.
NodeTool@0은 특정 Node 버전을 설치하여 실행의 재현성을 보장합니다.
설치 단계는 실행할 때마다 CLI를 새로 가져옵니다. 더 빠른 빌드를 위해 node_modules를 캐시하거나 버전을 고정할 수 있지만, 간단하게 시작하십시오.
중요한 것은 실행 단계입니다. 어떤 단언(assertion)이라도 실패하면 apidog run은 0이 아닌 값으로 종료되고, 스크립트 작업이 실패하며, 전체 빌드가 빨간색으로 변합니다.

$(...) 참조는 파이프라인 변수입니다. SCENARIO_ID, STAGING_ENV_ID, 그리고 특히 APIDOG_ACCESS_TOKEN은 다음 단계에서 가져오며, 여기에 하드코딩되지 않습니다.

4단계: 시크릿을 올바른 방식으로 저장

액세스 토큰은 절대 YAML에 일반 텍스트로 저장되어서는 안 됩니다. 리포지토리에 읽기 권한이 있는 사람은 누구든지 이를 볼 수 있으며, 이는 Apidog 프로젝트에 대한 접근 권한을 부여합니다.

시크릿 파이프라인 변수를 사용하십시오:

Azure DevOps에서 파이프라인을 열고 편집을 선택한 다음 변수(공유 변수 그룹의 경우 라이브러리)를 선택합니다.
APIDOG_ACCESS_TOKEN을 추가하고 토큰을 붙여넣습니다.
자물쇠 아이콘을 전환하여 시크릿으로 표시합니다. Azure는 이를 암호화하고 로그에서 마스킹합니다.

시크릿 변수는 셸 환경에 자동으로 주입되지 않습니다. 단계에서 명시적으로 매핑해야 합니다. env를 통해 시크릿을 전달하도록 실행 단계를 업데이트하십시오:

 - script: |
 apidog run https://api.apidog.com/api/v1/test-scenarios/$(SCENARIO_ID) \
 -t $(APIDOG_ACCESS_TOKEN) \
 -e $(STAGING_ENV_ID)
 displayName: 'Run API tests'
 env:
 APIDOG_ACCESS_TOKEN: $(APIDOG_ACCESS_TOKEN)

SCENARIO_ID와 STAGING_ENV_ID는 시크릿이 아니어도 됩니다. 가독성을 위해 일반 변수로 취급하거나, 여러 파이프라인에서 재사용하는 변수 그룹으로 옮기십시오. 많은 시크릿을 관리하는 팀의 경우, Azure Key Vault로 변수 그룹을 지원하여 한 곳에서 로테이션이 이루어지도록 할 수 있습니다.

5단계: 읽기 쉬운 테스트 보고서 게시

빨간색 빌드는 뭔가 깨졌다는 것을 알려줍니다. 무엇이 깨졌는지는 알려주지 않습니다. 해결책은 CLI가 보고서를 생성하고 Azure가 이를 표시하도록 하는 것입니다.

Apidog CLI는 결과를 보고서 파일에 쓸 수 있습니다. 출력 형식(사람을 위한 HTML, Azure의 기본 테스트 보기를 원한다면 JUnit 스타일 XML)과 출력 디렉터리를 지정한 다음 해당 디렉터리를 게시하십시오.

사람이 읽을 수 있는 아티팩트의 경우:

 - script: |
 apidog run https://api.apidog.com/api/v1/test-scenarios/$(SCENARIO_ID) \
 -t $(APIDOG_ACCESS_TOKEN) \
 -e $(STAGING_ENV_ID) \
 -r html \
 --out-dir $(Build.ArtifactStagingDirectory)/api-report
 displayName: 'Run API tests'
 env:
 APIDOG_ACCESS_TOKEN: $(APIDOG_ACCESS_TOKEN)

 - task: PublishBuildArtifacts@1
 condition: always()
 inputs:
 pathToPublish: $(Build.ArtifactStagingDirectory)/api-report
 artifactName: api-test-report
 displayName: 'Publish API test report'

두 가지를 주목하십시오. 첫째, condition: always()는 테스트 단계가 실패하더라도 게시 단계가 실행되도록 합니다. 이것이 핵심인데, 무엇인가 깨졌을 때 보고서가 가장 필요하기 때문입니다. 둘째, CLI 버전에 대해 apidog run --help를 통해 정확한 리포터 플래그(-r, --reporter 또는 유사한 것)와 출력 옵션을 확인한 다음, 예제를 일치하도록 조정하십시오.

추세 그래프와 함께 Azure의 내장된 테스트 탭에서 결과를 보고 싶다면, CLI가 JUnit XML을 생성하도록 하고 XML을 가리키는 PublishTestResults@2 작업을 추가하십시오. 이는 단일 파일이 아니라 빌드 전반에 걸쳐 단언(assertion)별 기록을 제공합니다.

6단계: 게이트를 현실로 만들기

파이프라인을 연결하는 것과 강제하는 것은 다릅니다. 기본적으로 실패하는 빌드는 Azure DevOps에 요구하도록 지시하지 않는 한, 누구도 병합하는 것을 막지 않습니다.

main에 브랜치 정책을 설정하십시오:

리포지토리(Repos)로 이동한 다음 브랜치(Branches)에서 main을 찾아 브랜치 정책(Branch policies)을 엽니다.
빌드 유효성 검사(Build Validation)를 추가하고 파이프라인을 선택합니다.
필수(required)로 설정합니다.

이제 API 테스트 파이프라인이 통과할 때까지 풀 리퀘스트를 main으로 병합할 수 없습니다. 이것이 실행되는 테스트와 보호하는 테스트의 차이입니다. 이를 켜기 전에는 대시보드가 있었지만, 그 후에는 게이트가 생기는 것입니다.

현실적인 데이터 기반 예시

단발성 시나리오는 명확한 오류를 잡습니다. 실제 API는 유효한 페이로드, 엣지 케이스, 500 대신 400을 반환해야 하는 잘못된 형식의 요청 등 다양한 입력으로 동일한 엔드포인트를 실행해야 합니다.

Apidog는 데이터 기반 테스트를 지원합니다: CSV 또는 JSON 데이터 세트를 시나리오에 첨부하면, 각 행당 한 번씩 실행되며, 해당 행의 값을 요청 및 단언(assertion)에 대체합니다. 예를 들어, 로그인 시나리오는 유효한 사용자, 잘못된 비밀번호, 잠긴 계정, 그리고 빈 본문에 대해 각기 예상되는 상태 코드를 가지고 행을 실행할 수 있습니다.

파이프라인에서는 명령의 형태가 변하지 않습니다. 동일한 시나리오에 대해 apidog run을 계속 호출합니다. 데이터 세트는 시나리오와 함께 이동하므로 하나의 CLI 호출이 모든 행을 처리합니다. Apidog에서 새로운 엣지 케이스를 추가하면, 다음 파이프라인 실행은 YAML 편집 없이 이를 감지합니다. 이것이 테스트 로직을 파이프라인이 아닌 도구에 보관하는 것의 장점입니다. 커버리지가 증가하는 동안 파이프라인은 지루하게 유지됩니다.

일반적인 문제 및 해결 방법

엔드포인트가 손상되었음에도 빌드가 통과합니다. 거의 항상 종료 코드 문제입니다. CLI가 실패 시 0이 아닌 값을 반환하는지 확인하고(2단계), 이를 무시하지 않는지 확인하십시오. 끝에 || true가 붙거나 다른 명령으로 끝나는 다중 명령 스크립트는 실패를 숨길 수 있습니다. apidog run 호출을 스크립트 블록의 마지막 의미 있는 명령으로 유지하십시오.
apidog: command not found. 설치 단계가 실행되지 않았거나, 테스트 단계 후에 실행되었거나, 에이전트 셸이 볼 수 없는 경로에 설치되었습니다. npm install -g apidog-cli가 실행 단계 이전에 나타나는지 확인하십시오. 일부 자체 호스팅 에이전트에서는 전역 npm bin이 PATH에 없을 수 있습니다. 대신 로컬로 설치하고 npx apidog run ...을 통해 호출하십시오.
CI에서는 인증에 실패하지만 로컬에서는 작동합니다. 시크릿이 단계에 도달하지 못하고 있습니다. 시크릿 변수는 env:를 통해 매핑되어야 합니다(4단계). 자동으로 주입되지 않습니다. 또한 토큰이 끝에 새 줄이나 따옴표와 함께 붙여넣어지지 않았는지 확인하십시오.
테스트가 잘못된 환경을 호출합니다. -e 값이 잘못된 Apidog 환경을 가리키거나, 환경의 기본 URL이 여전히 localhost를 참조합니다. 전용 Staging 환경을 유지하고, 변수가 접근 가능하고 CI에 안전한 URL로 해결되도록 하며, 해당 ID를 명시적으로 CLI에 전달하십시오.
실행마다 불안정한 합격/불합격. 일반적으로 공유 가능한 변경 가능한 상태(shared mutable state) 문제입니다. 레코드를 생성하는 테스트와 나중에 충돌하는 실행이 있을 수 있습니다. 시나리오를 자체 포함하도록 만드십시오: 필요한 것을 생성하고, 단언하고, 정리하거나, 실행마다 고유한 식별자를 사용하여 재실행이 어제의 데이터와 충돌하지 않도록 하십시오. 다른 도구에서 마이그레이션하는 경우, Newman 없이 CI에서 API 테스트를 실행하는 방법에 설명된 패턴이 동일한 격리 문제를 다룹니다.

기본 사항을 넘어

핵심 파이프라인이 안정되면, 몇 가지 확장이 효과를 발휘합니다:

야간 실행을 예약합니다. schedules 트리거를 추가하여 새벽 2시에 스테이징을 대상으로 전체 스위트를 실행하면, 아무도 코드를 푸시하지 않는 날에도 데이터 변경 또는 타사 API 변경으로 인한 드리프트를 감지할 수 있습니다.
빠르고 느린 스위트를 분리합니다. 모든 PR에서 빠른 피드백을 위해 빠른 스모크 시나리오를 실행하고, main으로 병합할 때 전체 회귀 스위트를 실행합니다. 두 개의 파이프라인 정의, 동일한 CLI를 사용합니다.
매트릭스에서 여러 환경을 테스트합니다. 파이프라인 매트릭스를 사용하여 동일한 시나리오를 스테이징 및 사전 프로덕션 환경에 대해 각기 다른 환경 ID로 병렬로 실행합니다.
병합뿐만 아니라 배포도 게이트로 막습니다. 다단계 파이프라인에서 API 테스트 단계를 배포 단계 앞에 배치하여, 테스트 실패 시 병합뿐만 아니라 릴리스까지 중단시킵니다.

이들 각각은 동일한 기반에 대한 작은 추가 사항입니다: 깔끔하게 종료되는 CLI와 종료 코드를 존중하는 파이프라인.

자주 묻는 질문

Azure Pipelines에서 API 테스트를 실행하기 위해 코드를 작성해야 하나요? 아닙니다. Apidog에서 시각적으로 테스트 시나리오를 구축하고 파이프라인은 단일 CLI 명령으로 이를 실행합니다. 유일한 "코드"는 구성이며 테스트 로직이 아닌 azure-pipelines.yml 자체입니다. 완전히 스크립트 기반 테스트를 선호한다면 여전히 그렇게 할 수 있지만, 이 워크플로우의 요점은 이를 건너뛰는 것입니다.
기존 Postman 컬렉션을 Azure Pipelines에서 대신 실행할 수 있나요? 네, 일반적으로 Newman 또는 유사한 러너를 사용하여 가능합니다. 옵션을 비교 중이라면, Apidog는 Postman 컬렉션을 직접 가져오므로 별도의 도구 체인을 유지 관리할 필요 없이 기존 테스트를 가져와 동일한 CLI를 통해 실행할 수 있습니다. 비교를 위해 Newman 없이 CI에서 API 테스트를 실행하는 방법을 참조하십시오.
테스트는 어디를 가리켜야 하나요; 스테이징 또는 프로덕션? 거의 항상 스테이징 또는 브랜치별 미리보기 환경입니다. 쓰기 작업이 많은 테스트를 프로덕션에 대해 실행하면 실제 데이터가 오염되고 실제 부작용을 유발할 수 있습니다. 안전한 기본 URL을 가진 CI를 위한 전용 Apidog 환경을 유지하고, 해당 ID를 -e와 함께 CLI에 전달하십시오.
파이프라인은 테스트 실패 여부를 어떻게 아나요? 종료 코드를 통해 압니다. apidog run은 모든 단언(assertion)이 통과하면 0을 반환하고, 하나라도 실패하면 0이 아닌 코드를 반환합니다. Azure Pipelines는 0이 아닌 종료 시 스크립트 작업을 실패로 처리하며, 이는 빌드 실패로 이어집니다. 게이트를 신뢰할 수 있도록 echo $?로 로컬에서 한 번 확인하십시오.
YAML뿐만 아니라 Azure DevOps Classic (UI) 파이프라인에서도 작동하나요? 네. 동일한 단계가 적용됩니다. "Use Node" 작업, npm install -g apidog-cli를 실행하는 명령줄 작업, 그리고 apidog run ...을 실행하는 또 다른 명령줄 작업을 추가하십시오. YAML은 리포지토리에 저장되고 버전 관리되기 때문에 권장되지만, 러너는 단계가 어떻게 정의되는지에 상관하지 않습니다.
Microsoft 호스팅 에이전트 대신 자체 호스팅 에이전트를 사용할 수 있나요? 네. 자체 호스팅 에이전트는 동일하게 작동합니다. Node.js가 설치되어 있고 에이전트의 PATH에 전역 npm bin이 있는지 확인하거나, npx를 통해 CLI를 호출하면 됩니다. 자체 호스팅 에이전트는 스테이징 API가 사설 네트워크 내부에서만 접근 가능한 경우에 유용합니다.

마무리

성공적인 CI 빌드는 코드가 컴파일되었다는 의미뿐만 아니라 API가 실제로 작동한다는 의미여야 합니다. Azure Pipelines에서 이를 달성하려면 네 가지 조치가 필요합니다: Apidog에서 실제 테스트 시나리오를 설계하고, Apidog CLI로 헤드리스 방식으로 실행하며, 종료 코드가 빌드 상태를 결정하도록 하고, 병합 전에 빌드가 통과하도록 요구하는 것입니다. 이 루프가 실행되면, 모든 푸시는 가장 신중한 팀원이 검토하는 것과 동일한 정밀 조사를 매번 자동으로 받게 될 것입니다.

이것이 유지 보수 가능한 이유는 분리 때문입니다. 테스트 로직은 API 사양과 가깝고 확장이 쉬운 Apidog에 있습니다. 파이프라인은 얇은 래퍼(wrapper)로 남아 있습니다. 설치, 실행, 보고. API가 성장함에 따라 도구에 시나리오와 데이터 행을 추가하면, 파이프라인은 편집 없이 자신의 한 가지 작업을 계속 수행합니다.

연결할 준비가 되셨습니까? Apidog를 다운로드하고, 테스트 시나리오를 구축하고, CLI 실행 명령을 가져와 azure-pipelines.yml에 넣으십시오. 다음 회귀는 고객이 아닌 기계에 의해 발견될 것입니다.

버튼