DEV Community

Cover image for Playwright 테스트에서 API 응답 검증 방법
Rihpig
Rihpig

Posted on • Originally published at apidog.com

Playwright 테스트에서 API 응답 검증 방법

Playwright 테스트는 통과했지만 고객은 “차트 숫자가 틀렸다”고 보고합니다. 확인해 보니 API가 잘못된 페이로드를 200 OK로 반환했고, E2E 테스트는 화면에 차트가 렌더링되는지만 확인했습니다. 이 간극을 줄이려면 브라우저 테스트에 API 단언(assertion)을 얇게 추가하고, Apidog와 같은 도구로 API 계약, 스키마, 응답 의미를 별도로 검증해야 합니다.

지금 Apidog를 사용해 보세요

요약

Playwright의 request 픽스처와 page.route 인터셉터를 OpenAPI 기반 Apidog 시나리오와 함께 사용하면 UI 테스트와 API 테스트를 같은 계약 위에서 실행할 수 있습니다.

핵심은 다음과 같습니다.

  • openapi.yaml을 단일 진실 소스(source of truth)로 둡니다.
  • Playwright에서는 핵심 API 스모크 테스트와 UI 플로우를 검증합니다.
  • Apidog에서는 스키마, 연쇄 API 시나리오, 오류 경로를 깊게 검증합니다.
  • 두 스위트를 CI에서 함께 실행해 계약 변경을 빠르게 감지합니다.

소개

Playwright는 브라우저 자동화에 강력합니다. Playwright API testing 문서를 보면 request.get()과 expect(response.status()).toBe(200)만으로 API 테스트를 쉽게 추가할 수 있어 보입니다.

하지만 실제 프로젝트에서는 다음 문제가 빠르게 발생합니다.

  • 상태 코드만 확인하고 응답 스키마는 확인하지 않는 테스트가 늘어남
  • UI 테스트와 API 테스트가 서로 다른 fixture를 사용함
  • OpenAPI 사양과 테스트 데이터가 동기화되지 않음
  • 백엔드가 느리거나 불안정할 때 오프라인으로 API를 mock하기 어려움

해결 방법은 OpenAPI 사양을 계약으로 취급하는 것입니다. 같은 openapi.yaml을 기준으로 Playwright request 호출, page.route stub, Apidog 시나리오를 구성합니다.

도구를 먼저 설치하려면 Apidog 다운로드 후 아래 단계를 진행하십시오.

이 글에서는 다음을 구현합니다.

  • Playwright 테스트에서 API 단언을 어디까지 넣을지 결정하는 기준
  • 재사용 가능한 request fixture 패턴
  • Playwright와 Apidog 간 fixture 공유 방식
  • CI에서 두 스위트를 함께 실행하는 GitHub Actions 예시
  • mocking, schema drift 감지, retry 정책
  • 대안 도구 비교

테스트 도구 선택에 대한 더 넓은 맥락은 QA 엔지니어를 위한 API 테스트 도구를 참고하십시오.

Playwright 테스트와 API 단언 간의 간극

일반적인 Playwright 테스트는 다음을 확인합니다.

  1. 로그인한다.
  2. 대시보드로 이동한다.
  3. 차트나 테이블이 보이는지 확인한다.

이 테스트는 사용자 플로우가 작동하는지 알려줍니다. 하지만 API가 올바른 데이터를 반환하는지는 보장하지 않습니다.

다음 문제는 UI 테스트만으로 놓치기 쉽습니다.

1. 페이로드 형태 회귀

API가 기존 total_count 대신 totalCount를 반환합니다.

{
  "totalCount": 42
}
Enter fullscreen mode Exit fullscreen mode

UI가 이를 0으로 처리하거나 fallback 값을 보여줘도 Playwright 테스트는 “숫자가 보인다”는 이유로 통과할 수 있습니다.

2. 비즈니스 로직 이탈

할인 API가 계약된 15% 대신 10% 할인을 적용합니다.

UI는 API 응답을 그대로 렌더링하므로 E2E 테스트는 통과합니다. 하지만 실제 금액은 잘못됩니다.

3. 오류 경로 미검증

E2E 테스트는 보통 happy path 중심입니다.

하지만 API에는 다음과 같은 오류 분기가 있습니다.

  • 만료된 토큰
  • rate limit
  • 부분 실패
  • idempotency 충돌
  • webhook 재시도 실패
  • 4xx / 5xx 응답

이 경로는 별도 API 테스트 없이는 거의 실행되지 않습니다.

역할 분리: Playwright와 Apidog

모든 API 테스트를 Playwright에 넣는 방식은 처음에는 단순합니다. 하지만 엔드포인트가 많아지고, “주문 생성 → 주문 조회 → 주문 취소 → 환불 webhook 검증” 같은 상태 기반 시나리오가 필요해지면 유지보수가 어려워집니다.

권장 분리는 다음과 같습니다.

  • Playwright

    • UI 플로우 검증
    • 핵심 API smoke assertion
    • page.route 기반 network stub
    • 사용자 행동 경계에서의 검증

  • Apidog

    • OpenAPI 스키마 적합성 검증
    • 연쇄 API workflow 검증
    • 계약 준수 검증
    • 오류 경로 검증
    • mock server 기반 오프라인 개발

두 도구가 같은 OpenAPI 사양을 사용하면 테스트의 기준점이 하나로 유지됩니다.

계약 우선 접근 방식은 설계 우선 API 워크플로우에서 더 자세히 다룹니다. Postman에서 전환을 검토 중이라면 자체 호스팅 Postman 대안도 참고하십시오.

Playwright와 Apidog 간 fixture 공유 방법

프로젝트 루트에 OpenAPI 사양을 둡니다.

.
├── openapi.yaml
├── fixtures/
│   └── order.json
├── tests/
│   ├── fixtures/
│   │   └── api.ts
│   └── orders.spec.ts
└── playwright.config.ts
Enter fullscreen mode Exit fullscreen mode

openapi.yaml은 API 계약입니다. Playwright는 요청 helper와 fixture를 통해 이 계약을 따르고, Apidog는 같은 파일을 import해 endpoint, request example, schema assertion을 생성합니다.

1. 공유 fixture 파일 만들기

fixtures/order.json:

{
  "sku": "SKU-123",
  "quantity": 2,
  "subtotal_cents": 50000,
  "currency": "KRW"
}
Enter fullscreen mode Exit fullscreen mode

이 파일은 Playwright와 Apidog에서 모두 같은 request body로 사용합니다.

2. Playwright API fixture 작성 

// tests/fixtures/api.ts
import { test as base, APIRequestContext, expect } from '@playwright/test';
import { readFileSync } from 'fs';
import path from 'path';

type ApiFixtures = {
  apiRequest: APIRequestContext;
  authToken: string;
  sampleOrder: Record<string, unknown>;
};

export const test = base.extend<ApiFixtures>({
  apiRequest: async ({ playwright }, use) => {
    const ctx = await playwright.request.newContext({
      baseURL: process.env.API_BASE_URL ?? 'https://api.staging.example.com',
      extraHTTPHeaders: {
        Accept: 'application/json',
        'Content-Type': 'application/json',
      },
    });

    await use(ctx);
    await ctx.dispose();
  },

  authToken: async ({ apiRequest }, use) => {
    const res = await apiRequest.post('/auth/token', {
      data: {
        email: 'qa@example.com',
        password: process.env.QA_PASSWORD,
      },
    });

    expect(res.status()).toBe(200);

    const body = await res.json();
    await use(body.access_token);
  },

  sampleOrder: async ({}, use) => {
    const raw = readFileSync(
      path.join(__dirname, '..', '..', 'fixtures', 'order.json'),
      'utf8',
    );

    await use(JSON.parse(raw));
  },
});

export { expect };
Enter fullscreen mode Exit fullscreen mode

이제 각 테스트는 @playwright/test 대신 이 fixture 파일에서 test와 expect를 가져옵니다.

3. Playwright에서 핵심 API 단언 추가 

// tests/orders.spec.ts
import { test, expect } from './fixtures/api';

test('POST /orders returns a valid order with 15 percent discount', async ({
  apiRequest,
  authToken,
  sampleOrder,
}) => {
  const res = await apiRequest.post('/orders', {
    headers: {
      Authorization: `Bearer ${authToken}`,
    },
    data: {
      ...sampleOrder,
      coupon: 'SAVE15',
    },
  });

  expect(res.status()).toBe(201);

  const body = await res.json();

  expect(body).toMatchObject({
    id: expect.any(String),
    status: 'pending',
    discount_pct: 15,
    total_cents: expect.any(Number),
  });

  expect(body.total_cents).toBeLessThan(
    sampleOrder.subtotal_cents as number,
  );
});
Enter fullscreen mode Exit fullscreen mode

Playwright에서는 모든 필드를 검증하려고 하지 마십시오. 대신 비즈니스적으로 중요한 필드만 명시적으로 검증합니다.

예:

  • 할인율
  • 상태값
  • 총액
  • 권한별 응답 차이
  • 사용자에게 직접 노출되는 데이터

나머지 스키마 전체 검증은 Apidog 시나리오에서 담당합니다.

Apidog에서 같은 OpenAPI 사양 사용하기

Apidog에서는 다음 순서로 설정합니다.

  1. Apidog 프로젝트를 엽니다.
  2. Import를 클릭합니다.
  3. 저장소의 openapi.yaml을 선택합니다.
  4. 생성된 endpoint, request example, schema를 확인합니다.
  5. fixtures/order.json과 동일한 payload를 환경 변수 또는 데이터 세트로 저장합니다.
  6. POST /orders 시나리오를 만듭니다.
  7. 응답을 Order schema에 대해 검증합니다.
  8. discount_pct, total_cents 같은 비즈니스 필드를 assertion으로 추가합니다.

Apidog 시나리오는 다음 역할을 합니다.

  • 필수 필드 누락 감지
  • 타입 변경 감지
  • enum 값 변경 감지
  • 응답 schema drift 감지
  • 연쇄 요청 간 데이터 전달 검증

Playwright는 높은 가치의 의미론적 단언을 수행하고, Apidog는 수동으로 놓치기 쉬운 schema 전체를 검증합니다.

사양 기반 테스트가 처음이라면 설계 우선 API 워크플로우를 참고하십시오.

Apidog + Playwright 워크플로우 설정

아래는 CI까지 연결하는 기본 구현 순서입니다.

1단계: OpenAPI 사양을 저장소 루트에 둔다 

openapi.yaml
Enter fullscreen mode Exit fullscreen mode

이 파일을 코드처럼 관리하십시오.

  • PR 리뷰 필수
  • breaking change는 명시적으로 기록
  • request / response example 유지
  • schema와 실제 구현 간 drift 감지

아직 OpenAPI 사양이 없다면 FastAPI, NestJS 등 프레임워크의 OpenAPI export 기능으로 초안을 만든 뒤 수동으로 정리합니다.

Apidog는 HAR 파일을 가져와 실제 트래픽에서 사양을 역설계할 수도 있습니다.

2단계: Playwright 설치 및 설정 

npm init playwright@latest
Enter fullscreen mode Exit fullscreen mode

package.json에 테스트 스크립트를 추가합니다.

{
  "scripts": {
    "test:e2e": "playwright test"
  }
}
Enter fullscreen mode Exit fullscreen mode

playwright.config.ts에서는 staging API와 retry 정책을 명시합니다.

import { defineConfig } from '@playwright/test';

export default defineConfig({
  retries: 2,
  use: {
    baseURL: process.env.APP_BASE_URL ?? 'http://localhost:3000',
    trace: 'on-first-retry',
  },
});
Enter fullscreen mode Exit fullscreen mode

3단계: Apidog 시나리오 계층 추가

Apidog에서 중요한 사용자 여정별 시나리오를 만듭니다.

예:

  • 회원가입
  • 로그인
  • 결제
  • 주문 취소
  • 환불
  • webhook 전달
  • 토큰 만료
  • rate limit

각 시나리오는 API 호출의 시퀀스입니다. 이전 응답에서 값을 추출해 다음 요청에 전달합니다.

예:

POST /auth/token
  → access_token 저장

POST /orders
  → order_id 저장

GET /orders/{order_id}
  → status 검증

POST /orders/{order_id}/cancel
  → cancellation status 검증
Enter fullscreen mode Exit fullscreen mode

Apidog CLI로 CI에서 실행 가능한 시나리오를 내보냅니다.

apidog-cli run ./apidog/scenarios/checkout.json
Enter fullscreen mode Exit fullscreen mode

4단계: Playwright에서 network stub 사용

UI가 실제 백엔드 데이터에 의존하지 않도록 page.route를 사용할 수 있습니다.

import { test, expect } from './fixtures/api';

test('dashboard renders cached order list when offline', async ({
  page,
  sampleOrder,
}) => {
  await page.route('**/api/orders', async (route) => {
    await route.fulfill({
      status: 200,
      contentType: 'application/json',
      body: JSON.stringify({
        orders: [sampleOrder],
      }),
    });
  });

  await page.goto('/dashboard');

  await expect(page.getByTestId('order-row')).toHaveCount(1);
});
Enter fullscreen mode Exit fullscreen mode

주의할 점은 page.route stub을 실제 API 테스트의 대체물로 사용하지 않는 것입니다.

  • stub: UI 격리용
  • Apidog scenario: 실제 API 계약 검증용

같은 fixture를 사용하되 목적은 분리합니다.

5단계: GitHub Actions에서 두 스위트 실행 

name: tests

on: [push, pull_request]

jobs:
  playwright:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm ci

      - run: npx playwright install --with-deps

      - run: npx playwright test
        env:
          API_BASE_URL: ${{ secrets.API_BASE_URL }}
          APP_BASE_URL: ${{ secrets.APP_BASE_URL }}
          QA_PASSWORD: ${{ secrets.QA_PASSWORD }}

  apidog:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm i -g apidog-cli

      - run: apidog-cli run ./apidog/scenarios/checkout.json --reporters cli,junit
        env:
          API_BASE_URL: ${{ secrets.API_BASE_URL }}
          QA_PASSWORD: ${{ secrets.QA_PASSWORD }}
Enter fullscreen mode Exit fullscreen mode

어느 job이든 실패하면 merge를 차단합니다.

--reporters junit를 사용하면 CI에서 실패한 assertion을 더 쉽게 추적할 수 있습니다. GitHub Actions의 matrix, cache, artifact 설정은 GitHub Actions 문서를 참고하십시오.

전담 QA 조직이 없는 팀이라면 QA 엔지니어를 위한 API 테스트 도구에서 스위트 소유권을 나누는 방식을 확인할 수 있습니다.

6단계: schema drift 감지

매일 예약 job을 실행해 현재 openapi.yaml과 실제 API 응답을 비교합니다.

감지해야 할 변경 예:

  • 필드명 변경
  • 타입 변경
  • 필수 필드 제거
  • enum 값 변경
  • response status code 변경
  • nullable 여부 변경

이 작업은 “잘못된 payload와 함께 200 OK가 반환되는 문제”를 조기에 잡는 데 효과적입니다.

고급 기술 및 전문가 팁

Playwright trace viewer 활성화

playwright.config.ts에 다음을 설정합니다.

use: {
  trace: 'on-first-retry',
}
Enter fullscreen mode Exit fullscreen mode

불안정한 테스트가 실패하면 다음을 함께 확인할 수 있습니다.

  • network call
  • DOM snapshot
  • console log
  • screenshot
  • action timeline

API 쪽에서는 Apidog HTML report와 함께 사용하면 UI 문제인지 API 변경인지 빠르게 분리할 수 있습니다.

Apidog mock server로 오프라인 실행

백엔드가 배포 중이거나 staging DB가 초기화되는 동안에는 Apidog mock server를 사용합니다.

패턴은 다음과 같습니다.

  • 로컬 Playwright는 Apidog mock server를 바라봄
  • Apidog scenario는 실제 backend 또는 mock server 둘 다 실행 가능
  • OpenAPI example response를 기준으로 UI 개발 지속

Mock이 중요한 테스트 자동화 흐름은 AI 지원 API 테스트 생성에서도 다룹니다.

retry는 작게 유지

Playwright retry는 보통 2회로 충분합니다.

export default defineConfig({
  retries: 2,
});
Enter fullscreen mode Exit fullscreen mode

테스트가 통과하기 위해 5회 retry가 필요하다면 테스트 또는 시스템에 문제가 있는 것입니다.

Apidog scenario도 요청당 retry를 과도하게 늘리지 마십시오. 일시적인 네트워크 문제를 흡수할 정도만 설정합니다.

schema drift는 기본적으로 실패 처리

Apidog가 schema mismatch를 감지하면 CI를 실패시켜야 합니다.

일시적으로 허용해야 한다면 환경 변수로 명시합니다.

ALLOW_SCHEMA_DRIFT=true
Enter fullscreen mode Exit fullscreen mode

그리고 PR에 이유를 남기도록 팀 규칙을 둡니다.

테스트를 우선순위별로 태그 지정

Playwright에서는 smoke, regression, nightly를 분리합니다.

test('checkout flow @smoke', async ({ page }) => {
  // ...
});
Enter fullscreen mode Exit fullscreen mode

권장 실행 전략:

  • 모든 push: @smoke
  • main 대상 PR: regression
  • nightly: 전체 Playwright + 전체 Apidog scenario

상태를 공유하는 테스트는 serial 모드를 사용합니다.

test.describe.configure({ mode: 'serial' });
Enter fullscreen mode Exit fullscreen mode

피해야 할 실수

  • status === 200만 검증하는 것
  • bearer token을 fixture에 하드코딩하는 것
  • Playwright와 Apidog가 서로 다른 payload를 사용하는 것
  • OpenAPI 사양을 수동 문서처럼 방치하는 것
  • page.route stub을 실제 API 테스트로 착각하는 것
  • CI에서 Apidog CLI 실행을 생략하는 것

AI 기반 API를 테스트한다면 AI 에이전트 API 테스트 방법도 참고하십시오. 비결정론적 응답은 일반 REST API보다 assertion 설계가 더 중요합니다.

대안 및 도구 비교

스택 장점 단점 가장 적합한 경우
Playwright 단독 (request fixture) 하나의 도구로 UI와 API smoke test 작성 가능 깊은 schema 검증, 연쇄 scenario, 오류 경로 커버리지가 약함 소규모 팀, 단순 API
Playwright + Postman 성숙한 Postman 생태계, Newman CLI OpenAPI와 collection이 어긋날 수 있음, 두 가지 진실 소스 발생 이미 Postman을 표준으로 쓰는 팀
Playwright + Apidog 단일 OpenAPI 소스, schema validation, mock, CLI, design-first workflow 두 도구 학습 필요, 사양 관리 규율 필요 사양 기반으로 UI/API 회귀를 함께 잡고 싶은 팀
Cypress + cy-api plugin Cypress 사용자에게 익숙함 API 테스트 기능이 제한적이고 plugin 의존 기존 Cypress 코드베이스
Pact consumer-driven contract에 강함 학습 곡선, broker 인프라, UI 테스트와 직접 연결되지 않음 내부 API consumer가 많은 microservice 조직

SOAP 또는 ReadyAPI 기반 테스트에서 전환한다면 SoapUI Groovy 스크립트 대안, ReadyAPI 대안을 참고하십시오.

로컬 우선 API 호출 도구를 찾는다면 REST 클라이언트 VSCode 확장도 볼 만합니다.

실제 사용 사례

전자상거래 결제

소매팀은 Playwright로 장바구니에서 결제 완료까지의 UI 플로우를 검증합니다.

동시에 Apidog에서는 다음 API 체인을 검증합니다.

POST /payment-intents
POST /fraud-checks
POST /inventory/reservations
POST /orders
Enter fullscreen mode Exit fullscreen mode

결제 게이트웨이가 응답 필드를 error_code에서 errorCode로 변경했을 때 Apidog schema 검증이 이를 빠르게 감지합니다. Playwright만 있었다면 단순히 “결제 실패 화면이 보인다”는 수준에서 멈췄을 가능성이 높습니다.

차트가 있는 SaaS 대시보드

B2B 분석 제품은 Playwright로 차트 렌더링을 확인합니다.

Apidog에서는 집계 API가 다음 값을 올바르게 반환하는지 검증합니다.

  • 합계
  • 평균
  • 백분위수
  • 시간 구간별 series
  • 필터별 segment

차트는 정상적으로 렌더링되어도 API가 이상치(outlier)를 누락하면 데이터는 잘못됩니다. 이 문제는 API 계층에서 잡아야 합니다.

webhook 기반 workflow

핀테크 팀은 Playwright로 사용자 포털을 검증하고, Apidog로 webhook 전달과 retry 로직을 검증합니다.

검증 항목 예:

  • 중복 webhook ID 거부
  • signature 유효성
  • idempotency key 처리
  • retry 횟수
  • eventual consistency 시간이 30초 미만인지

결론

Playwright는 브라우저 플로우 테스트에 적합합니다. 하지만 깊은 API 계약 검증을 모두 담당하기에는 한계가 있습니다.

Playwright와 Apidog를 함께 사용하면 다음 구조를 만들 수 있습니다.

  • 단일 openapi.yaml을 계약으로 사용
  • Playwright와 Apidog가 같은 fixture 공유
  • UI 테스트와 API schema 검증 분리
  • page.route로 UI 격리
  • Apidog scenario로 연쇄 API workflow 검증
  • mock server로 오프라인 개발 지원
  • CI에서 UI/API 회귀를 동시에 차단

처음부터 모든 API를 옮길 필요는 없습니다.

가장 중요한 여정 하나를 고르십시오.

예:

  • 회원가입
  • 로그인
  • 결제
  • 주문 생성
  • 환불
  • webhook 처리

그 여정에 대해 다음만 먼저 구성하면 됩니다.

  1. openapi.yaml 정리
  2. Playwright fixture 작성
  3. 핵심 API smoke assertion 추가
  4. Apidog scenario 생성
  5. GitHub Actions에서 두 스위트 실행

그다음 endpoint와 scenario를 점진적으로 확장하십시오.

자주 묻는 질문

Apidog 없이 Playwright 테스트에서 API를 검증할 수 있나요?

네. Playwright의 request fixture와 expect를 사용하면 됩니다.

다만 다음이 필요해지면 Apidog 같은 전용 도구가 더 적합합니다.

  • 전체 schema validation
  • 연쇄 API scenario
  • mock server
  • 오류 경로 테스트
  • OpenAPI 기반 계약 검증

장단점 비교는 QA 엔지니어를 위한 API 테스트 도구를 참고하십시오.

이 설정을 사용하려면 OpenAPI 사양이 필요한가요?

필수는 아니지만, 권장됩니다.

OpenAPI 사양이 없으면 Playwright와 Apidog가 같은 계약을 공유하지 못합니다. 그러면 request example, response schema, fixture를 두 곳에서 따로 관리해야 합니다.

기존 API에서 OpenAPI 초안을 생성한 뒤 점진적으로 정리하는 방식으로 시작할 수 있습니다.

인증은 어떻게 처리하나요?

테스트 시작 시 인증 API에서 새 token을 발급받으십시오.

Playwright에서는 fixture로 노출합니다.

authToken: async ({ apiRequest }, use) => {
  const res = await apiRequest.post('/auth/token', {
    data: {
      email: 'qa@example.com',
      password: process.env.QA_PASSWORD,
    },
  });

  const body = await res.json();
  await use(body.access_token);
};
Enter fullscreen mode Exit fullscreen mode

Apidog에서는 같은 값을 environment variable에 저장해 다음 요청에서 사용합니다.

오래된 token을 fixture에 하드코딩하지 마십시오.

Apidog 시나리오가 Playwright를 완전히 대체할 수 있나요?

아닙니다.

Apidog는 API workflow 검증에 적합하지만 브라우저를 렌더링하지 않습니다. 다음 검증에는 Playwright가 필요합니다.

  • 클릭 플로우
  • 화면에 보이는 텍스트
  • 레이아웃
  • 접근성 흐름
  • 브라우저 이벤트
  • 실제 사용자 상호작용

두 도구는 대체 관계가 아니라 보완 관계입니다.

안정적인 staging backend가 없으면 어떻게 하나요?

Apidog mock server를 사용하십시오.

OpenAPI 사양에 정의된 example response를 기반으로 mock server를 실행하고, Playwright를 해당 mock server로 연결합니다.

이렇게 하면 백엔드가 불안정해도 UI 개발과 테스트를 계속할 수 있습니다. staging이 안정화되면 같은 테스트를 실제 backend에 대해 다시 실행합니다.

CI를 빠르게 유지하려면 어떻게 해야 하나요?

테스트를 우선순위별로 나누십시오.

  • push: smoke
  • PR: regression
  • nightly: full suite

Playwright는 worker를 늘려 병렬 실행합니다.

export default defineConfig({
  workers: 4,
});
Enter fullscreen mode Exit fullscreen mode

Apidog scenario는 CLI의 parallel 옵션을 사용해 병렬화합니다.

CI를 위해 Apidog 유료 플랜이 필요한가요?

Apidog CLI는 로컬과 CI에서 scenario 실행에 사용할 수 있습니다. 다만 팀 규모, 협업 기능, 현재 가격 정책에 따라 플랜 조건은 달라질 수 있으므로 도입 전 최신 가격 정책을 확인하십시오.

Top comments (0)