CI/CD 자동화 API 테스트 베스트 프랙티스 12가지

결함 있는 API를 배포하는 녹색 파이프라인은 파이프라인이 전혀 없는 것보다 나쁩니다. 이는 고객이 티켓을 접수할 때까지 팀에 모든 것이 괜찮다고 말해줍니다. CI의 대부분 API 테스트 설정은 처음에는 강력하게 시작하지만 조용히 부패합니다. 몇몇 엔드포인트가 커버된 후, 테스트 스위트가 불안정해지고, 누군가 소음을 막기 위해 continue-on-error를 추가하며, 한 분기 안에 테스트는 실행되지만 아무도 신뢰하지 않게 됩니다. 파이프라인은 실패를 무시하는 법을 배웠기 때문에 녹색입니다.

해결책은 더 많은 테스트가 아닙니다. 그것은 금요일 오후의 핫픽스나 세 서비스 깊이의 스키마 변경과 같은 실제 환경의 압력 속에서도 견딜 수 있도록 테스트를 설계하고, 실행하며, 게이트하는 방법에 대한 몇 가지 결정에 달려 있습니다. 이 가이드는 GitHub Actions, GitLab CI 또는 이미 사용 중인 모든 러너에 복사할 수 있는 구체적인 설정을 포함하여 이러한 12가지 결정을 안내합니다.

이 모든 것을 관통하는 공통적인 원칙은 동일합니다. API 테스트는 API 계약서 옆에 있어야 하고, 하나의 휴대용 명령으로 실행되어야 하며, 계약이 깨졌을 때 큰 소리로 실패해야 합니다. 이것이 우리가 Apidog와 함께 구축할 워크플로우입니다. Apidog는 스펙을 설계하고, 시각적으로 어설션을 작성하며, Apidog CLI를 통해 CI에서 전체 스위트를 헤드리스로 실행할 수 있는 API 플랫폼입니다. 앱에서 한 번 테스트를 설계한 다음, 단일 명령으로 어떤 파이프라인에서든 정확히 동일한 스위트를 실행할 수 있습니다. 따라하고 싶다면 Apidog를 다운로드하고 자신의 API를 준비하세요.

버튼

CI/CD 자체가 처음이라면, 간단히 말해 이렇습니다. 지속적 통합(CI)은 모든 커밋에서 테스트를 실행하고, 지속적 배포(CD)는 테스트를 통과한 빌드를 승격시킵니다. CI/CD란 무엇이며 어떻게 작동하는가에서 더 자세한 내용을 확인할 수 있습니다. 이 글의 나머지 부분은 여러분이 파이프라인을 가지고 있으며 API 테스트 부분이 실제로 그 역할을 다하기를 바란다고 가정합니다.

1. API 테스트를 파이프라인에 넣으세요. 잊어버리고 열지 않은 탭에 두지 마세요.

첫 번째 모범 사례는 사람들이 건너뛰는 것입니다. API 테스트를 수동으로 결정하지 않고, 모든 푸시마다 자동으로 실행하세요. 릴리스 전에 수동으로 실행하는 테스트 스위트는 안전망이 아니라 체크리스트에 불과합니다. 실행해야겠다고 기억할 때쯤이면, 문제를 일으킨 변경 사항은 이미 6개의 커밋 뒤에 있습니다.

중요한 단계에 스위트를 연결하세요. 대부분의 팀에서는 풀 리퀘스트에서 이루어지므로, 손상된 API가 main 브랜치에 도달하는 대신 병합을 차단합니다. 다음은 GitHub Actions의 최소 구성입니다.

name: API Tests
on:
  pull_request:
    branches: [main]
jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Install Apidog CLI
        run: npm install -g apidog-cli
      - name: Run API test suite
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t "$SCENARIO_ID" \
            -e "$APIDOG_ENV_ID" \
            -r cli,junit \
            --out-dir ./test-results
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
          SCENARIO_ID: ${{ vars.SCENARIO_ID }}
          APIDOG_ENV_ID: ${{ vars.APIDOG_ENV_ID }}

이것이 전체 통합입니다. 모든 어설션이 통과하면 CLI는 0으로 종료되고, 하나라도 실패하면 0이 아닌 코드로 종료되므로, GitHub는 추가 설정 없이 실제 실패 시 작업을 빨간색으로 표시합니다. 전체 GitHub 설정은 GitHub Actions에서 API 테스트를 자동화하는 방법에서 다룹니다. 이 패턴은 모든 러너에 적용됩니다.

첫 번째 모범 사례의 핵심은 테스트 결정이 개발자가 아닌 기계에 의해 이루어져야 한다는 것입니다. 사람은 잊지만, 파이프라인은 그렇지 않습니다.

2. 실행 명령을 CI 공급업체 간에 이식 가능하게 유지하세요.

파이프라인은 마이그레이션됩니다. 팀은 Jenkins에서 GitHub Actions로 이동하거나, 새 저장소를 위해 GitLab을 추가하거나, 규정 준수를 위해 자체 호스팅 러너를 구축합니다. API 테스트가 한 공급업체의 플러그인 생태계에 고정되어 있다면, 모든 마이그레이션은 다시 작성하는 것을 의미합니다.

이를 피하는 방법은 모든 러너가 호출할 수 있는 단일 셸 명령으로 테스트 호출을 만드는 것입니다. Apidog CLI를 사용하면 누가 호출하든 스위트를 실행하는 명령은 동일합니다.

apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t "$SCENARIO_ID" -e "$ENV_ID" -r cli,junit

이 동일한 라인은 GitHub Actions의 run 단계, GitLab의 script 블록, Jenkins 셸 스테이지 또는 Travis script 섹션에서 작동합니다. 주변을 감싸는 부분만 변경됩니다. 예를 들어 GitLab의 경우:

api-tests:
  image: node:20
  script:
    - npm install -g apidog-cli
    - apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t "$SCENARIO_ID" -e "$ENV_ID" -r cli,junit
  artifacts:
    when: always
    reports:
      junit: ./test-results/*.xml

무거운 작업(요청 오케스트레이션, 어설션, 환경 해결)이 CLI에 있고 테스트 정의가 Apidog에 있기 때문에 파이프라인 YAML은 간결하게 유지됩니다. 공급업체를 전환할 때, 600줄이 아닌 6줄만 복사하면 됩니다. 만약 Jenkins 스택을 사용 중이라면 CI/CD를 위해 Apidog 자동화 테스트를 Jenkins와 통합하는 방법에 Jenkins 버전이 상세히 설명되어 있습니다.

3. 상태 코드뿐만 아니라 동작을 어설션하세요.

200 OK만 확인하는 테스트는 API가 빈 배열, 잘못된 통화, 또는 클라이언트가 객체를 기대하는 곳에 null을 반환하더라도 통과할 것입니다. 상태 코드만 확인하는 테스트는 녹색 파이프라인이 손상된 응답을 배포하는 가장 큰 단일 원인입니다.

진정한 어설션은 응답의 형태와 내용을 확인합니다. 즉, 존재하는 필드, 그들의 유형, 소비자에게 중요한 값들을 확인합니다. Apidog에서는 응답을 기반으로 시각적으로 이러한 어설션을 구축하므로, 머릿속으로 JSONPath를 추측하는 대신 실제 페이로드를 어설션하게 됩니다. 견고한 주문 조회 테스트는 상태가 200이고, order.total이 숫자이며, currency가 보낸 값과 같고, items 배열이 비어 있지 않음을 어설션합니다. 이 각각은 독립적으로 실패하는 별도의 어설션이므로, 빨간색 빌드는 어떤 계약이 깨졌는지 알려줍니다.

세 가지 규칙은 어설션이 시간이 지나도 유효하도록 만듭니다.

데이터가 아닌 계약을 어설션하세요. total이 숫자임을 확인하고, 49.99와 같음을 확인하지 마세요. 정확한 값은 변하지만, 타입은 변하지 않습니다.
어설션당 하나의 관심사. 6개의 검사를 하나의 어설션으로 묶으면 어떤 것이 실패했는지 숨겨집니다.
불행한 경로도 커버하세요. 잘못된 입력에 대한 400 오류와 토큰 누락에 대한 401 오류도 계약의 일부입니다. 이들이 여전히 올바르게 작동하는지 테스트하세요.

리팩터링 후에도 유효한 어설션을 작성하는 방법에 대한 심층적인 내용은 API 어설션 가이드를 참조하세요. 강력한 어설션은 스모크 테스트를 계약 테스트로 바꾸며, 계약 테스트는 중요한 회귀를 잡아냅니다.

4. 환경 및 비밀을 하드코딩된 값이 아닌 구성으로 관리하세요.

테스트는 다양한 대상에 대해 실행됩니다. 로컬 스택, 스테이징 API, 프로덕션 스모크 엔드포인트 등이 있습니다. 기본 URL, 인증 토큰, 테넌트 ID는 이들 사이에서 모두 변경됩니다. 이러한 값 중 하나라도 테스트에 하드코딩하면 스테이징 테스트가 실수로 프로덕션을 건드리거나, 토큰이 Git 히스토리에 남게 될 수 있습니다.

환경을 이름이 지정된 구성으로 유지하고 차이점을 주입하세요. Apidog에서 환경은 하나의 대상에 대한 기본 URL과 변수를 포함합니다. CI 실행 시 -e 플래그로 사용할 환경을 선택합니다. 파이프라인은 리포지토리의 파일에서가 아니라 비밀 저장소에서 액세스 토큰을 제공합니다.

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t "$SCENARIO_ID" \
  -e "$STAGING_ENV_ID" \
  -r cli,junit

다른 -e 값을 가리키는 동일한 시나리오가 프로덕션 스모크 테스트가 됩니다. 테스트 자체는 변경되지 않으며, 단지 테스트가 해결하는 환경만 달라집니다. APIDOG_ACCESS_TOKEN은 GitHub Secrets, GitLab CI/CD 변수 또는 러너의 자격 증명 관리자에 저장하고 이름으로 참조하세요. 규칙은 간단합니다. 환경마다 다른 모든 것이나 비밀 정보는 구성이며, 구성은 런타임에 주입됩니다.

5. 파이프라인이 신뢰할 수 있도록 테스트를 결정론적으로 만드세요.

불안정한(flaky) 테스트는 코드와 무관한 이유로 실패하는 테스트입니다. 또한 파이프라인의 신뢰도를 파괴하는 가장 빠른 방법이기도 합니다. 일단 스위트가 '가끔 실패'하기 시작하면, 개발자들은 초록색이 될 때까지 작업을 다시 실행하기 시작하며, 이는 이제 실제 실패가 가짜 실패의 소음 속에 숨겨진다는 것을 의미합니다.

대부분의 API 테스트 불안정성은 몇 가지 예측 가능한 원인에서 비롯됩니다.

공유된 가변 상태. 두 개의 테스트가 동일한 이메일로 사용자를 생성하거나, 한 테스트가 다른 테스트가 삭제한 데이터에 의존하는 경우. 각 테스트는 자체 데이터를 설정하고 해제하거나, 격리된 테넌트를 사용해야 합니다.
타이밍 가정. 비동기 결과가 준비되기 전에 어설션하는 경우. 작업이 최종적으로 수행되는 경우, 고정된 시간(초)만큼 대기하는 대신 조건을 폴링하세요.
제어할 수 없는 실제 종속성. 속도 제한이 있는 타사 결제 샌드박스 또는 유지 보수 중인 업스트림 서비스. 이러한 경계를 모의(mock) 처리하여 테스트가 다른 사람의 가동 시간이 아닌 API를 측정하도록 하세요. Apidog는 스키마에서 불안정한 종속성에 대한 모의를 설정할 수 있어, 빌드에서 외부 불안정성을 방지합니다.
순서 의존성. 특정 순서로 실행될 때만 통과하는 테스트. 러너는 병렬로 실행되므로 스위트는 어떤 순서로 실행되어도 통과해야 합니다.

결정론적 특성은 사람들이 존중하는 파이프라인과 회피하는 파이프라인의 차이입니다. 초기에 여기에 엔지니어링 노력을 투자하세요. 불안정한 테스트는 복리로 이자를 낳습니다.

6. API 테스트 단계를 빠르게 유지하세요. 그렇지 않으면 개발자들이 우회할 것입니다.

모든 풀 리퀘스트마다 20분씩 걸리는 테스트 스위트는 개발자들이 불평하고 결국 비활성화하는 부담이 됩니다. CI에서 속도는 '있으면 좋은' 것이 아니라, 스위트가 아예 실행되도록 유지하는 요소입니다. 대부분의 팀이 목표로 하는 것은 PR에서 5분 미만의 API 단계입니다.

몇 가지 방법으로 목표에 도달할 수 있습니다.

독립적인 시나리오를 병렬로 실행하세요. 테스트가 결정론적이라면(모범 사례 5), 병렬 작업으로 분할하거나 러너가 분산 처리하도록 하는 데 아무런 문제가 없습니다. 독립적인 스위트는 나란히 실행될 수 있습니다.
테스트를 계층화하세요. 모든 PR에서 빠른 스모크 스위트를 실행하고, main 브랜치로 병합 시 또는 야간 스케줄에 따라 전체 회귀 스위트를 실행하세요. 모든 테스트가 모든 커밋을 게이트할 필요는 없습니다.
설치를 캐시하세요. apidog-cli의 전역 npm 설치를 실행 간에 캐시하면 모든 작업의 설정 시간을 단축할 수 있습니다.
도움이 되는 곳에서는 빠르게 실패하고, 그렇지 않은 곳에서는 끝까지 완료하세요. PR에서는 첫 번째 실패에서 중단하여 빠른 피드백을 제공하세요. 야간 전체 실행에서는 CLI의 --on-error continue를 사용하여 하나의 손상된 엔드포인트가 다른 40개의 손상된 엔드포인트를 숨기지 않도록 하세요.

다음은 GitHub Actions의 계층화된 패턴으로, PR에서는 빠른 스모크 실행을, 스케줄에 따라 전체 스위트를 실행합니다.

on:
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 2 * * *'   # nightly full regression

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g apidog-cli
      - name: Run suite
        run: |
          if [ "${{ github.event_name }}" = "pull_request" ]; then
            apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t "$SMOKE_ID" -e "$ENV_ID" -r cli,junit --out-dir ./test-results
          else
            apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t "$FULL_ID" -e "$ENV_ID" -r cli,junit --on-error continue --out-dir ./test-results
          fi
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

실행되는 빠른 단계는 비활성화되는 철저한 단계보다 가치가 높습니다.

7. 콘솔 텍스트의 벽이 아니라, 기계가 읽을 수 있는 결과를 게시하세요.

빌드가 실패했을 때, 'API 테스트가 실패했습니다'는 충분하지 않습니다. 어떤 어설션이, 어떤 시나리오에서, 어떤 요청에서 깨졌는지 알아야 합니다. 수천 줄의 콘솔 출력이 있는 빨간색 빌드는 테스트가 전혀 없는 것보다 나을 것이 거의 없습니다. 여전히 누군가가 그것을 읽어야 합니다.

해결책은 CI 서버가 기본적으로 파싱하는 형식으로 결과를 출력하는 것입니다. JUnit XML은 표준 CI 테스트 결과 형식이며, 거의 모든 플랫폼이 이를 읽을 수 있습니다. Apidog CLI는 junit 리포터를 사용하여 이를 작성합니다.

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t "$SCENARIO_ID" \
  -e "$ENV_ID" \
  -r cli,html,junit \
  --out-dir ./test-results

이 명령은 동일한 실행에 대한 세 가지 뷰를 출력합니다. 라이브 콘솔 출력을 위한 cli, 사람이 열람할 수 있는 보고서를 위한 html, 그리고 기계를 위한 junit입니다. 파이프라인이 XML을 가리키도록 설정하면 플랫폼이 이를 구조화된 테스트별 결과로 변환합니다.

      - name: Publish test report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: api-test-results
          path: ./test-results

if: always()에 주목하세요. 실행이 실패하더라도 보고서가 게시되기를 원합니다. 왜냐하면 실패한 실행이야말로 보고서가 가장 필요할 때이기 때문입니다. 그 효과는 분명합니다. 'API 빌드가 깨졌다' 대신에 '결제 시나리오의 cart-total 어설션이 실패하기 시작했다'는 메시지를 받게 되어, 디버깅 세션을 한 번의 시선으로 해결할 수 있습니다.

8. 브랜치 보호를 통해 스위트로 병합을 제어하세요.

아무것도 차단하지 않는 통과된 테스트 스위트는 단지 알림일 뿐입니다. CI의 목적은 손상된 코드를 병합할 수 없게 만드는 것이며, 이는 대부분의 팀이 구성하는 것보다 한 단계 더 나아간 브랜치 보호를 필요로 합니다.

종료 코드가 로컬 작업을 수행합니다. Apidog CLI는 어설션 실패 시 0이 아닌 값으로 종료되므로, 실제 실패 시 작업은 빨간색으로 변합니다. 그러나 PR에서 빨간색 작업은 확인이 필수로 지정될 때까지는 권고 사항에 불과합니다. GitHub에서는 main 브랜치에 API 테스트 확인을 필수 상태 확인으로 설정하세요. 병합 버튼은 초록색이 될 때까지 비활성화 상태로 유지됩니다. GitLab과 Bitbucket은 병합 요청 설정에서 이에 상응하는 기능을 제공합니다.

이것이 회귀를 잡아내는 스위트와 사후에 회귀를 기록하는 스위트의 차이입니다. 필수 확인 없이는 마감 압박을 받는 개발자가 병합 버튼을 클릭하면 손상된 API가 바로 옆에 빨간색 확인이 있음에도 배포됩니다. 게이트가 있으면 플랫폼이 이를 거부합니다. 테스트는 제안이 아니라 도구가 강제하는 규칙이 됩니다.

이것을 모범 사례 7의 기계가 읽을 수 있는 결과 및 커밋 상태 통합과 결합하면, Git 호스트는 PR에 정확한 실패 확인을 인라인으로 표시합니다. 피드백 루프가 닫힙니다. 푸시, 테스트, 차단, 수정, 통과, 병합.

9. API 스펙에서 테스트 커버리지를 생성하세요. 수동으로 작성하지 마세요.

API 테스트에서 가장 느린 부분은 테스트를 API와 동기화 상태로 유지하는 것입니다. 모든 새 엔드포인트에는 새 테스트가 필요하고, 변경된 모든 필드에는 업데이트된 어설션이 필요합니다. 수동으로 작업하면 테스트는 항상 API에 뒤처지게 되고, 그 격차에서 회귀가 발생합니다.

효율적인 방법은 계약을 기반으로 테스트를 구동하는 것입니다. API에 OpenAPI 스펙이 있다면, 스펙에서 테스트 스캐폴딩을 생성할 수 있습니다. 즉, 엔드포인트당 하나의 요청과 예상 응답 형태를 이미 설명하는 스키마를 포함합니다. Apidog에서는 스펙과 테스트가 동일한 작업 공간에 있으므로, 문서화된 엔드포인트에서 직접 테스트 시나리오를 구축할 수 있습니다. OpenAPI 스펙에서 API 테스트 컬렉션을 생성하는 방법에서 생성 흐름을 안내합니다.

이것은 CI에서 중요합니다. 왜냐하면 스펙 기반 테스트는 특정하고 흔한 버그, 즉 문서가 약속하는 것과 API가 반환하는 것 사이의 불일치를 잡아내기 때문입니다. 스펙에서 생성된 테스트가 라이브 API에 대해 실행될 때, 불일치가 발생하면 빌드가 실패합니다. 계약이 실행 가능해지는 것입니다. 비즈니스 의미를 인코딩하는 어설션은 여전히 수동으로 작성하지만, '이 엔드포인트가 존재하고 문서화된 형태를 반환하는가'와 같은 반복적인 코드를 직접 작성할 필요는 없습니다. 스펙이 그 부담을 지도록 하세요.

10. 시나리오를 중복하지 않고 엣지 케이스를 커버하기 위해 데이터 기반 테스트를 사용하세요.

동일한 엔드포인트는 입력에 따라 다르게 동작합니다. 유효한 주문, 신용 한도를 초과하는 주문, 알 수 없는 SKU를 가진 주문, 지원되지 않는 통화의 주문 등입니다. 각각에 대해 별도의 시나리오를 작성하면 스위트가 아무도 유지 관리하지 않는 수백 개의 거의 동일한 테스트로 부풀어 오르게 됩니다.

데이터 기반 테스트는 하나의 시나리오를 여러 입력 행에 대해 실행합니다. 요청과 어설션을 한 번 정의한 다음, 케이스 테이블을 제공합니다. Apidog CLI는 -d 플래그로 데이터 파일을 받습니다.

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t "$SCENARIO_ID" \
  -e "$ENV_ID" \
  -d ./test-data/orders.csv \
  -r cli,junit \
  --out-dir ./test-results

orders.csv의 각 행은 자체적인 통과 또는 실패 여부를 가진 하나의 반복이 됩니다. 하나의 시나리오, 하나의 CLI 호출, 전체 엣지 케이스 커버리지, 그리고 어떤 입력 행이 실패했는지 보여주는 JUnit 보고서가 제공됩니다. 이는 스위트를 작게 유지하고 커버리지를 넓게 유지하여, CI에서 원하는 바를 정확히 충족합니다. CSV 또는 JSON을 이용한 데이터 기반 API 테스트 가이드에서는 데이터 파일 구조화에 대해 더 깊이 다룹니다.

이 패턴은 유효성 검사 로직과 가격 책정 규칙, 즉 단일 엔드포인트가 가장 많은 분기점과 가장 많은 방식으로 조용히 회귀할 수 있는 곳에서 가장 큰 효과를 발휘합니다.

11. 실제 환경에 대해 배포 후 스모크 테스트를 실행하세요.

스테이징 환경에서 통과하는 테스트는 빌드가 좋다는 것을 알려줍니다. 하지만 배포가 성공했는지는 알려주지 않습니다. 구성 불일치, 누락된 환경 변수, 잘못 라우팅된 로드 밸런서, 만료된 인증서 등 이 모든 것들은 모든 병합 전 테스트를 통과하고 실제로 배포된 환경에서만 문제가 발생합니다.

보호막은 배포 후에 실제 대상에 대해 실행되는 스모크 테스트입니다. 이는 작고 빠른 스위트로, 핵심 경로, 인증 흐름, 가장 중요한 읽기 및 쓰기 엔드포인트를 프로덕션 또는 새로 배포된 환경에 대해 테스트합니다. 실행 명령이 휴대 가능하고(모범 사례 2) 환경이 단순히 구성이므로(모범 사례 4), 이는 다른 -e 값으로 실행되는 동일한 스위트입니다.

  smoke-after-deploy:
    needs: deploy
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g apidog-cli
      - name: Smoke test production
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t "$SMOKE_SCENARIO_ID" \
            -e "$PROD_ENV_ID" \
            -r cli,junit \
            --out-dir ./smoke-results
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

스모크 테스트가 실패하면 사용자가 알아채기 전에 롤백해야 한다는 신호입니다. 블루-그린 또는 카나리 배포를 실행하는 팀의 경우, 트래픽을 전환하기 전에 새 환경에 대해 스모크 스위트를 실행하여 첫 실제 사용자가 손상된 배포를 발견하는 일이 없도록 합니다. 비용은 파이프라인 시간 1분입니다. 다른 방법은 지원 티켓을 통해 문제를 알게 되는 것입니다.

12. 테스트 스위트를 완료하는 설정이 아니라, 유지 관리하는 코드로 취급하세요.

마지막 모범 사례는 사고방식입니다. CI 테스트 스위트는 완료하는 프로젝트가 아니라, 보호하는 API와 함께 유지 관리하는 자산입니다. 파이프라인이 신뢰할 수 있는 상태를 유지하는 팀은 불안정한 테스트를 버그로, 느린 단계를 기술 부채로, 커버리지의 공백을 발생 대기 중인 회귀로 간주합니다.

몇 가지 습관이 장기적으로 스위트를 건강하게 유지합니다.

기능과 함께 테스트를 추가하세요. 새로운 엔드포인트는 나중에 적용되지 않을 후속 PR이 아니라, 동일한 PR에서 시나리오와 함께 배포됩니다.
불안정한 테스트는 나타나는 날 바로 수정하세요. 격리된 불안정한 테스트는 초록불이 켜진 커버리지 공백입니다. continue-on-error가 영구적으로 사용되지 않도록 하세요.
스위트가 커버하지 않는 부분을 검토하세요. 주기적으로 어떤 엔드포인트에 어설션이 없는지 확인하세요. 테스트되지 않은 부분이 다음 서비스 중단이 시작되는 곳입니다.
파이프라인 구성을 버전 제어 시스템에 보관하세요. YAML, 환경 정의, 테스트 데이터 모두 리포지토리에 저장되어 다른 변경 사항과 마찬가지로 검토됩니다.

테스트 정의가 Apidog에 있고 파이프라인은 얇은 호출만 포함하므로, 대부분의 유지 보수는 쉬운 곳에서 이루어집니다. 앱에서 시나리오와 어설션을 추가하면 CI 구성은 거의 변경되지 않습니다. 이를 제대로 수행하는 팀은 YAML을 관리하는 데 시간을 보내는 대신 커버리지를 개선하는 데 시간을 보냅니다. 대규모 스위트를 구성하는 방법에 대한 더 넓은 시야는 Apidog 테스트 스위트: API 테스트 자동화를 위한 더 스마트한 방법을 참조하세요.

종합하기

이 12가지 모범 사례는 서로를 강화합니다. 휴대 가능한 실행 명령은 배포 후 스모크 테스트를 사소하게 만듭니다. 결정론적 테스트는 병렬 처리를 안전하게 하여 단계를 빠르게 유지하고, 개발자들이 계속 사용하도록 합니다. 기계가 읽을 수 있는 결과는 텍스트의 벽 대신 특정 실패 지점을 가리키므로 브랜치 보호를 의미 있게 만듭니다. 스펙 기반 및 데이터 기반 테스트는 유지 보수가 느려지지 않으면서 스위트를 포괄적으로 유지합니다.

공통 기반은 테스트를 계약에 가깝게 유지하고 하나의 명령으로 실행 가능하게 만드는 것입니다. 이것이 Apidog 워크플로우를 한 문장으로 요약한 것입니다. 한 곳에서 API와 테스트를 설계한 다음, apidog run 명령으로 어떤 파이프라인에서든 정확히 동일한 스위트를 실행하세요. CLI는 실패 시 0이 아닌 값으로 종료되고, CI가 파싱할 JUnit을 출력하며, GitHub Actions, GitLab, Jenkins 또는 자체 호스팅 러너가 호출하든 동일하게 작동합니다.

작게 시작하세요. 실제 어설션과 필수 상태 확인을 사용하여 하나의 중요한 시나리오를 PR 파이프라인에 연결하세요. 그 루프를 신뢰할 수 있게 만든 다음, 계층화된 실행, 데이터 기반 엣지 케이스, 배포 후 스모크 테스트 등 나머지를 추가하세요. 신뢰할 수 있는 파이프라인은 무언가가 정말로 고장났을 때만 빨간색으로 변하고, 배포가 정말로 안전할 때만 초록색으로 변합니다. Apidog를 다운로드하고 오늘 첫 시나리오를 구축하세요.

버튼

자주 묻는 질문

CI와 CI/CD의 API 테스트 차이점은 무엇인가요? CI(지속적 통합)는 모든 커밋 또는 풀 리퀘스트에서 API 테스트를 자동으로 실행하여 회귀를 조기에 잡아냅니다. CD(지속적 배포)는 빌드가 이러한 검사를 통과하면 배포 대상으로 승격시킵니다. API 테스트는 두 단계 모두에 포함됩니다. 병합 전 스위트는 통합을 제어하고, 배포 후 스모크 스위트는 배포를 검증합니다. 동일한 Apidog CLI 명령이 두 단계 모두에 사용됩니다.

파이프라인에서 API 테스트를 실행하기 위해 코드를 작성해야 하나요? 아닙니다. Apidog에서 요청과 어설션을 시각적으로 구축한 다음, 단일 apidog run 명령으로 헤드리스로 실행합니다. 파이프라인은 이 하나의 명령만 필요하며, 이는 CI 구성을 간결하게 유지하고 QA 엔지니어가 코드 기반 프레임워크를 유지 관리할 필요 없이 테스트를 소유할 수 있도록 합니다. 전체 가이드는 CI/CD에서 API 테스트를 자동화하는 방법에 있습니다.

CI에서 API 테스트가 불안정해지는 것을 어떻게 막을 수 있나요? 가장 큰 세 가지 원인은 공유된 가변 테스트 데이터, 비동기 작업에 대한 타이밍 가정, 그리고 제어할 수 없는 타사 종속성입니다. 각 테스트에 자체 데이터를 제공하고, 고정된 시간만큼 대기하는 대신 비동기 조건을 폴링하며, 제어할 수 없는 외부 경계를 모의(mock) 처리하세요. 어떤 순서로든 어떤 실행에서든 통과하는 스위트가 목표입니다.

실패하는 API 테스트가 병합을 차단하도록 하려면 어떻게 해야 하나요? 두 가지 방법이 있습니다. 첫째, 테스트 러너는 실패 시 0이 아닌 값으로 종료되어야 합니다. Apidog CLI는 어설션 실패 시 이를 수행하므로, 작업은 자동으로 빨간색으로 변합니다. 둘째, 해당 작업을 Git 호스트의 브랜치 보호 규칙에서 필수 상태 확인으로 표시하세요. 병합 버튼은 확인이 통과될 때까지 비활성화 상태로 유지됩니다.

GitHub Actions, GitLab, Jenkins에서 동일한 API 테스트를 실행할 수 있나요? 네, 가능합니다. 테스트 로직은 Apidog에 있고 파이프라인은 apidog run만 호출하므로, 명령은 모든 공급업체에서 동일합니다. 주변의 YAML 또는 파이프라인 스크립트만 변경됩니다. 이러한 이식성 덕분에 CI 공급업체 마이그레이션이 재작성이 아닌 6줄 수정으로 끝납니다. GitHub에 특화된 설정은 GitHub Actions에서 API 테스트를 자동화하는 방법을 참조하세요.

API 테스트 단계는 얼마나 빨라야 하나요? 풀 리퀘스트에서 5분 이내를 목표로 하세요. PR에서 빠른 스모크 스위트를 실행하고 야간에는 전체 회귀 스위트를 실행하며, 독립적인 시나리오를 병렬화하고 CLI 설치를 캐시하여 이를 달성할 수 있습니다. 느린 단계는 개발자들이 결국 비활성화하게 되는 단계이며, 이는 목적에 부합하지 않습니다.