ตรวจสอบ API ด้วย Playwright: วิธีการเช็ค Response อย่างละเอียด

การทดสอบ Playwright ของคุณผ่านฉลุย ปุ่มเข้าสู่ระบบคลิกได้ แดชบอร์ดแสดงผล ชาร์ตก็ขึ้นรูป แต่แล้วลูกค้าก็รายงานข้อผิดพลาด: ตัวเลขในชาร์ตผิดเพี้ยน คุณเจาะลึกและพบว่า API คืนสถานะ 200 พร้อมกับเพย์โหลดที่ผิดรูปแบบ และชุดทดสอบแบบ E2E ของคุณไม่เคยสังเกตเห็นเลย เพราะมันตรวจสอบแค่ว่าพิกเซลปรากฏบนหน้าจอ นี่คือช่องว่างที่การทดสอบเบราว์เซอร์เพียงอย่างเดียวไม่สามารถปิดได้ และเป็นจุดที่การยืนยัน API กลายเป็นสิ่งที่ไม่สามารถละเลยได้ เครื่องมืออย่าง Apidog ให้วิธีในการตรวจสอบสัญญา API, สคีมา และความหมายของการตอบกลับด้วยความเข้มงวดเดียวกับที่คุณให้กับโฟลว์ UI ของคุณ จากนั้นรันชุดทดสอบทั้งสองร่วมกันใน CI

TL;DR

คุณสามารถตรวจสอบ API ในการทดสอบ Playwright ได้โดยการรวม Playwright’s request fixture และ page.route interceptor เข้ากับ Apidog scenarios ที่เรียกใช้ OpenAPI spec เดียวกัน แชร์ fixtures ผ่านไฟล์ spec เดียวกัน ยืนยัน response schemas ในทั้งสองเลเยอร์ และรันชุดทดสอบทั้งสองใน CI job เดียวกัน เพื่อให้การเปลี่ยนแปลงสัญญาใดๆ ล้มเหลวอย่างรวดเร็วในทั้งสองส่วน

บทนำ

Playwright เป็นเฟรมเวิร์กอัตโนมัติของเบราว์เซอร์เริ่มต้นสำหรับหลายทีมในปี 2026 และ เอกสารของ Playwright ทำให้การทดสอบ API ดูง่ายดาย: เพียงแค่เรียกใช้ request.get ไม่กี่ครั้ง, expect(response.status()).toBe(200) และคุณก็เสร็จสิ้น ปัญหาเริ่มต้นเมื่อคุณขยายขนาด คุณจะมีการทดสอบหลายร้อยรายการที่ตรวจสอบรหัสสถานะ แต่ไม่ใช่รูปร่างของการตอบกลับ ไม่มีแหล่งข้อมูลเดียวที่ใช้ร่วมกันระหว่างโฟลว์เบราว์เซอร์และโฟลว์ API ของคุณ และไม่มีวิธี mock API แบบออฟไลน์เมื่อแบ็กเอนด์ช้าหรือเสีย

การแก้ไขนั้นตรงไปตรงมา กำหนดให้ OpenAPI spec ของคุณเป็นสัญญาหลัก, ขับเคลื่อน Playwright request calls และ page.route interceptors จากสัญญานั้น, และรันชุด Apidog scenario กับ spec เดียวกันเพื่อตรวจสอบสคีมาเชิงลึก, ตรรกะทางธุรกิจ, และการตรวจสอบ request แบบต่อเนื่อง คุณจะได้รับผลตอบรับที่รวดเร็วใน CI, ขอบเขตความเป็นเจ้าของที่ชัดเจนระหว่างการทดสอบฟรอนต์เอนด์และแบ็กเอนด์, และไม่มี fixtures ซ้ำซ้อน หากคุณต้องการติดตั้งเครื่องมือนี้ก่อน ดาวน์โหลด Apidog แล้วกลับมาทำต่อ; ขั้นตอนด้านล่างนี้สมมติว่ามีพร้อมใช้งานในเครื่องของคุณ

นี่คือสิ่งที่คุณจะได้รับจากโพสต์นี้: โมเดลทางความคิดที่ชัดเจนว่าการยืนยัน API ควรอยู่ในส่วนใดของชุด Playwright, รูปแบบ request.fixture ที่ใช้งานได้, การตั้งค่าแบบทีละขั้นตอนสำหรับการแชร์ fixtures ระหว่าง Playwright และ Apidog, เคล็ดลับขั้นสูงสำหรับ CI และ mocking, และตารางเปรียบเทียบตัวเลือกหลักๆ สำหรับบริบทที่กว้างขึ้นเกี่ยวกับตัวเลือกเครื่องมือทดสอบ ดูมุมมองของเราเกี่ยวกับ เครื่องมือทดสอบ API สำหรับวิศวกร QA

ช่องว่างระหว่างการทดสอบ Playwright และการยืนยัน API

การทดสอบ Playwright ทั่วไปจะล็อกอิน, ไปยังหน้าหนึ่ง, และยืนยันว่าองค์ประกอบ UI บางอย่างปรากฏให้เห็น นั่นบอกคุณว่าโฟลว์ที่ผู้ใช้มองเห็นใช้งานได้ มันไม่ได้บอกอะไรคุณเกี่ยวกับ API ที่อยู่เบื้องหลัง มันมีสามรูปแบบความล้มเหลวที่เล็ดลอดไปได้:

ประการแรก, การถดถอยของรูปร่างเพย์โหลด. จุดสิ้นสุดคืนค่า 200 โดยเปลี่ยนชื่อฟิลด์จาก total_count เป็น totalCount UI อาจแก้ไขโดยอัตโนมัติหรือแสดงค่าศูนย์ การทดสอบ Playwright ของคุณเห็นตัวเลขบนหน้าจอและผ่าน

ประการที่สอง, การเปลี่ยนแปลงของตรรกะทางธุรกิจ. จุดสิ้นสุดส่วนลดใช้ส่วนลด 10 เปอร์เซ็นต์แทน 15 เปอร์เซ็นต์ตามสัญญา UI แสดงผลตามที่ API ส่งคืน ดังนั้นการทดสอบจึงผ่าน เฉพาะทีมการเงินเท่านั้นที่สังเกตเห็นในอีกหลายสัปดาห์ต่อมา

ประการที่สาม, ความครอบคลุมของเส้นทางข้อผิดพลาด. การทดสอบ Playwright เกือบทั้งหมดรันเส้นทางที่ปกติ API ของคุณมีหลายสิบสาขา 4xx และ 5xx: ข้อจำกัดอัตรา, โทเค็นหมดอายุ, ความล้มเหลวบางส่วน, ความขัดแย้งของ idempotency ไม่มีสิ่งใดได้รับการทดสอบเว้นแต่คุณจะเขียนชุดทดสอบ API แยกต่างหาก

คุณสามารถแก้ไขบางส่วนนี้ได้โดยการเพิ่ม request.get calls ภายใน Playwright specs ของคุณและยืนยัน response bodies นั่นใช้ได้สำหรับจุดสิ้นสุดจำนวนน้อย แต่มันจะล้มเหลวเมื่อคุณมี 200 จุดสิ้นสุดและต้องการสถานการณ์ต่อเนื่อง เช่น “สร้างคำสั่งซื้อ, ดึงคำสั่งซื้อ, ยกเลิกคำสั่งซื้อ, ตรวจสอบ webhook คืนเงิน” Playwright เป็นเฟรมเวิร์กสำหรับ automation เบราว์เซอร์เป็นหลัก; ไม่ได้ถูกสร้างมาสำหรับเวิร์กโฟลว์ API ที่มีสถานะ หรือความสะดวกสบายในการยืนยันระดับสคีมา นั่นคือสิ่งที่เครื่องมือทดสอบ API โดยเฉพาะเข้ามามีบทบาท

การแบ่งแยกที่ถูกต้องคือ:

• การทดสอบ Playwright ตรวจสอบโฟลว์ UI, การดักจับเครือข่าย, และชั้นบางๆ ของ API smoke checks ที่ขอบเขตของการกระทำของผู้ใช้
• Apidog scenarios ตรวจสอบการปฏิบัติตามสคีมา, เวิร์กโฟลว์ API ที่ต่อเนื่อง, การปฏิบัติตามสัญญา, และเส้นทางข้อผิดพลาดอย่างละเอียด

ชุดทดสอบทั้งสองใช้ OpenAPI spec เดียวกัน เพื่อให้คุณไม่เคยมีสองเวอร์ชันของความจริง สำหรับมุมมองที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับแนวทาง contract-first บทความของเราเกี่ยวกับ เครื่องมือการพัฒนา API แบบ design-first อธิบายว่าทำไม spec ถึงต้องเป็นผู้นำ

วิธีแชร์ Fixtures ระหว่าง Playwright และ Apidog

แหล่งข้อมูลเดียวที่เป็นจริงคือ OpenAPI spec ของคุณ ซึ่งมักจะเป็น openapi.yaml หรือ openapi.json ที่ root ของ repository Playwright อ่านมันสำหรับ typed request helpers และ example payloads; Apidog นำเข้าโดยตรงเพื่อเติมเต็มขั้นตอนของ scenario เมื่อใดก็ตามที่แบ็คเอนด์ส่งการเปลี่ยนแปลงสัญญา ชุดทดสอบทั้งสองจะรับทราบ

เริ่มต้นด้วยโฟลเดอร์ fixtures/ ที่เก็บข้อมูลทดสอบที่ใช้ซ้ำได้: ผู้ใช้, โทเค็น, sample payloads สร้างไฟล์ Playwright 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 };

ตอนนี้คุณนำเข้า test จากไฟล์ fixture นี้แทน @playwright/test ในแต่ละ spec และคุณมี apiRequest ที่เป็น typed, authToken ใหม่, และข้อมูล sampleOrder พร้อมใช้งาน ไฟล์ order.json เป็นเพย์โหลดเดียวกันที่ Apidog ใช้เป็น example body สำหรับ POST /orders ใน scenarios ของคุณ แก้ไขครั้งเดียว ชุดทดสอบทั้งสองก็เปลี่ยน

สำหรับฝั่ง Apidog ให้เปิดโปรเจกต์ คลิก "Import" และชี้ไปที่ openapi.yaml เดียวกัน Apidog จะสร้าง endpoints, request examples และ parameter schemas ได้ในไม่กี่วินาที จากนั้นบันทึก payload fixtures ของคุณเป็น Apidog "Environment Variables" หรือ "Data Sets":

// 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);
});

ภายใน Apidog ขั้นตอน scenario ที่ตรงกันจะส่งเพย์โหลดเดียวกัน จากนั้นรันการตรวจสอบ JSON Schema ในตัวกับคอมโพเนนต์ Order ใน openapi.yaml ซึ่งให้ความลึกแก่คุณ: ทุกฟิลด์จะถูกตรวจสอบประเภท, ฟิลด์ที่จำเป็นได้รับการตรวจสอบ, ค่า enum ถูกบังคับใช้ Playwright ตรวจจับการยืนยันเชิงความหมายที่มีมูลค่าสูง (discount_pct: 15); Apidog ตรวจจับทุกฟิลด์ที่เปลี่ยนแปลงไป แม้กระทั่งฟิลด์ที่คุณลืมยืนยันด้วยตนเอง หากคุณยังใหม่กับการทดสอบแบบ spec-driven คำแนะนำของเราเกี่ยวกับ เวิร์กโฟลว์ API แบบ design-first แสดงรูปแบบโดยรอบ

สำหรับทีมที่ใช้ Postman อยู่แล้วและกำลังพิจารณาการเปลี่ยนไปใช้เครื่องมืออื่น ทางเลือก Postman ที่โฮสต์เอง ครอบคลุมกลไกการย้ายข้อมูล

การตั้งค่าเวิร์กโฟลว์ Apidog + Playwright

นี่คือการตั้งค่าที่สะอาดและทำซ้ำได้ ซึ่งจะพาคุณจากศูนย์สู่ CI สองชุดทดสอบในเวลาประมาณหนึ่งชั่วโมง

ขั้นตอนที่ 1: One spec to rule them all. วาง openapi.yaml ไว้ที่ root ของ repository ปฏิบัติต่อมันเหมือนโค้ด: ต้องมีการตรวจสอบ PR, การเปลี่ยนแปลงที่สำคัญต้องมีการเพิ่มเวอร์ชันหลัก หากคุณยังไม่มี ให้สร้างฉบับร่างจาก routes ที่มีอยู่ของคุณโดยใช้ปลั๊กอินเฟรมเวิร์ก (FastAPI, NestJS และอื่นๆ สร้าง OpenAPI ได้โดยธรรมชาติ) จากนั้นแก้ไขด้วยตนเอง Apidog ยังสามารถ reverse-engineer spec จาก traffic ได้หากคุณนำเข้าไฟล์ HAR

ขั้นตอนที่ 2: เชื่อมต่อ Playwright. ติดตั้ง Playwright (npm init playwright@latest) และเพิ่มไฟล์ fixture ตามที่แสดงด้านบน เพิ่มสคริปต์ npm run test:e2e และ playwright.config.ts ที่ชี้ไปยังสภาพแวดล้อม staging ของคุณ ทำให้การทดสอบมีขนาดเล็ก; หนึ่ง scenario ต่อหนึ่ง spec

ขั้นตอนที่ 3: เพิ่มเลเยอร์ Apidog scenario. ภายในโปรเจกต์ Apidog ของคุณ นำเข้า openapi.yaml จากนั้นสร้าง scenario สำหรับ critical user journey แต่ละอัน: การลงทะเบียน, การชำระเงิน, การคืนเงิน, การส่ง webhook เป็นต้น แต่ละ scenario คือลำดับของการเรียก API พร้อมการยืนยันที่เชื่อมโยงกัน Apidog รองรับตัวแปรสภาพแวดล้อม, สคริปต์ก่อน request, และการยืนยันหลัง response ส่งออก scenario เป็น JSON ที่รันด้วย CLI ผ่าน Apidog CLI (apidog-cli run scenario.json)

ขั้นตอนที่ 4: การดักจับเครือข่ายใน Playwright. เมื่อ UI ดึงข้อมูลที่คุณไม่ต้องการเรียกใช้จริง ให้ใช้ page.route เพื่อดักจับและ stub การตอบกลับที่ stub มาจากไฟล์ fixture เดียวกัน ดังนั้นสัญญาจึงสอดคล้องกัน:

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);
});

จากนั้นใน Apidog รัน scenario GET /orders เดียวกันกับแบ็กเอนด์จริงของคุณหรือกับ Apidog mock server Fixture เดียวกัน, สองระดับของการตรวจสอบ

ขั้นตอนที่ 5: การรวม CI. เพิ่ม GitHub Actions workflow ที่รันทั้งสองชุดทดสอบพร้อมกัน:

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
  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

การล้มเหลวใน job ใด job หนึ่งจะบล็อกการรวมโค้ด ใช้ --reporters junit เพื่อให้ GitHub ใส่คำอธิบายประกอบการยืนยันที่ล้มเหลวใน PR เอกสาร GitHub Actions ครอบคลุมถึง matrix builds และ caching หากคุณต้องการขยายขนาด สำหรับทีมที่ไม่มีฟังก์ชัน QA โดยเฉพาะ เครื่องมือทดสอบ API สำหรับวิศวกร QA จะอธิบายวิธีมอบหมายความเป็นเจ้าของแต่ละชุดทดสอบ

ขั้นตอนที่ 6: การตรวจจับการเปลี่ยนแปลง. กำหนดเวลา job รายวันที่จะเปรียบเทียบ openapi.yaml ที่ใช้งานจริงกับเวอร์ชันที่ใช้ทดสอบครั้งล่าสุด หากฟิลด์มีการเปลี่ยนประเภท การเปรียบเทียบจะทำให้ build ล้มเหลวก่อนที่จะมีการทดสอบใดๆ รัน นี่เป็นการตรวจจับข้อผิดพลาดประเภท "200 OK แต่ payload ผิด" ที่เรากล่าวถึงตอนต้น

เทคนิคขั้นสูงและเคล็ดลับมือโปร

มีบางสิ่งที่ทำแล้วคุ้มค่าหลังจากตั้งค่าพื้นฐานเสร็จสิ้น

ปักหมุด Playwright trace viewer. ตั้งค่า trace: 'on-first-retry' ใน playwright.config.ts เมื่อการทดสอบที่รวนล้มเหลวใน CI คุณจะได้รับไทม์ไลน์เต็มรูปแบบของการเรียกเครือข่าย, DOM snapshots และ console logs จับคู่กับ apidog-cli --report html สำหรับฝั่ง API ทั้งสองอย่างจะแสดงให้คุณเห็นว่า UI เสียก่อนหรือ API เปลี่ยนแปลงไป

ใช้ Apidog mock servers สำหรับการรันแบบออฟไลน์. Apidog สามารถสร้าง mock server จาก OpenAPI spec ของคุณได้ในคลิกเดียว ชี้สภาพแวดล้อมการพัฒนาในเครื่องของคุณไปที่นั่นเมื่อทีมแบ็กเอนด์กำลัง deploy หรือฐานข้อมูล staging กำลังถูกรีเซ็ต ชุด Playwright ของคุณจะรันผ่านกับ mock และ Apidog scenarios ของคุณจะตรวจสอบแบ็กเอนด์จริงพร้อมกัน สำหรับข้อมูลเพิ่มเติมเกี่ยวกับรูปแบบนี้ ดูบทความของเราเกี่ยวกับ การสร้างการทดสอบ API ด้วย AI ที่ซึ่ง mocks เป็นหัวใจสำคัญ

จำกัดจำนวนครั้งที่ลองใหม่เป็นสองครั้ง. retries: 2 ใน playwright.config.ts หากการทดสอบต้องการการลองใหม่สามครั้งจึงจะผ่าน แสดงว่ามันรวนและคุณมีปัญหาจริงจัง อย่าปกปิดมันด้วย retries: 5 เช่นเดียวกันสำหรับ Apidog scenarios: ตั้งค่า retry: 1 ต่อ request สูงสุด

ให้ Build Fail เมื่อมีการเปลี่ยนแปลง schema. เมื่อ Apidog ตรวจพบความไม่ตรงกันของสคีมา ให้จบการทำงานด้วยรหัสที่ไม่ใช่ศูนย์โดยค่าเริ่มต้น อย่าปล่อยให้คำเตือนเล็ดรอดไป หากคุณต้องอนุญาตช่วง soft-fail ให้กำหนดเงื่อนไขด้วยตัวแปรสภาพแวดล้อมเช่น ALLOW_SCHEMA_DRIFT=true และกำหนดให้มีคอมเมนต์ใน PR อธิบายเหตุผล

แท็กการทดสอบตามลำดับความสำคัญ. ใช้ Playwright’s test.describe.configure({ mode: 'serial' }) สำหรับโฟลว์ที่มีสถานะ และแท็กอื่นๆ ด้วย @smoke, @regression, @nightly รัน smoke test ทุกครั้งที่ push, รัน regression test กับ PRs ไปยัง main, รัน nightly test ทั่วทั้งชุด Apidog scenario ทั้งหมด ช่วยประหยัดเวลา CI โดยไม่ลดความครอบคลุม

ข้อผิดพลาดที่พบบ่อยที่ควรหลีกเลี่ยง:

• ยืนยันเพียงแค่ status === 200 เพิ่มการตรวจสอบอย่างน้อยหนึ่งฟิลด์ใน body
• ฮาร์ดโค้ด bearer tokens ใน fixtures ใช้ beforeAll เพื่อดึงโทเค็นใหม่
• ปล่อยให้ Playwright และ Apidog นำเข้าไฟล์ fixture ที่แตกต่างกัน ควรมีแหล่งที่มาเดียว
• ข้าม Apidog CLI ใน CI เพราะ "เครื่องมือ UI ดีพอแล้ว" มันไม่ใช่; CLI คือสิ่งที่ทำให้ build ล้มเหลว
• Treating page.route stubs as a substitute for real API tests. พวกมันมีไว้สำหรับการแยกตัว ไม่ใช่ความครอบคลุม

สำหรับทีมที่สร้างการทดสอบด้วย AI คู่มือ วิธีทดสอบ API ของ AI agents ครอบคลุมกรณีที่ไม่แน่นอนที่ต้องดูแลเป็นพิเศษ

ทางเลือกและการเปรียบเทียบเครื่องมือ

มีการรวมเครื่องมือหลายอย่างที่สามารถตรวจสอบ API พร้อมกับการทดสอบเบราว์เซอร์ได้ นี่คือการจัดเรียงตัวเลือกหลักๆ

หากคุณมาจากเครื่องมือยุค SOAP เก่า บทความของเราเกี่ยวกับ ทางเลือกสคริปต์ Groovy ของ SoapUI และ ทางเลือก ReadyAPI ครอบคลุมเส้นทางการย้ายข้อมูล สำหรับเวิร์กโฟลว์แบบ local-first ส่วนเสริม VSCode สำหรับ REST client ก็คุ้มค่าที่จะอ่าน

การจับคู่ Playwright + Apidog ชนะสำหรับทีมที่มี OpenAPI spec, จัดส่งบริการหลายอย่าง, และต้องการ pipeline CI เดียวที่สามารถตรวจจับการถดถอยทั้ง UI และ API โดยไม่ต้องจ่ายค่าลิขสิทธิ์สองที่นั่งต่อวิศวกร

กรณีศึกษาในโลกจริง

การชำระเงินใน E-commerce. ทีมค้าปลีกรันการทดสอบ Playwright สำหรับโฟลว์ตั้งแต่รถเข็นจนถึงการยืนยัน และ Apidog scenarios สำหรับ API chain ของการตั้งใจชำระเงิน, การตรวจสอบการฉ้อโกง, และการลดสินค้าคงคลัง เมื่อเกตเวย์การชำระเงินเปลี่ยนฟิลด์ตอบกลับจาก error_code เป็น errorCode, Apidog ตรวจจับได้ใน 90 วินาที; Playwright จะแสดงหน้าจอ "การชำระเงินล้มเหลว" ทั่วไปและใช้เวลาหลายชั่วโมงในการแก้ไข

แดชบอร์ด SaaS พร้อมข้อมูลแผนภูมิ. ผลิตภัณฑ์วิเคราะห์ B2B ตรวจสอบการแสดงผล UI ด้วย Playwright snapshots และใช้ Apidog เพื่อยืนยันว่า endpoints การรวมข้อมูลคืนค่าผลรวม, เปอร์เซ็นไทล์ และอนุกรมที่แบ่งตามช่วงเวลาที่ถูกต้อง ข้อผิดพลาดที่ endpoint p99 latency ทิ้งค่าผิดปกติไปโดยไม่แจ้งให้ทราบ ถูกตรวจจับที่ชั้น API; แผนภูมิยังคงดูปกติ

เวิร์กโฟลว์ที่ขับเคลื่อนด้วย Webhook. ทีม Fintech ใช้ Playwright สำหรับพอร์ทัลที่ผู้ใช้เข้าถึง และ Apidog scenarios สำหรับการส่ง Webhook, ตรรกะการลองใหม่ (retry logic), และ idempotency การสคริปต์ของ Apidog ตรวจสอบว่า Webhook ID ซ้ำกันถูกปฏิเสธ, ลายเซ็นต์ถูกต้อง, และช่วงเวลา eventual-consistency อยู่ภายใน 30 วินาที

สรุป

Playwright เป็นเลิศในด้านโฟลว์เบราว์เซอร์ แต่ไม่ได้สร้างมาเพื่อการทดสอบ API เชิงลึก การจับคู่กับ Apidog ทำให้คุณได้:

• OpenAPI spec เดียวเป็นสัญญาหลักระหว่างชุดทดสอบทั้งสอง
• Fixtures ที่ใช้ร่วมกัน เพื่อให้ข้อมูลทดสอบไม่เคยเปลี่ยนแปลง
• การตรวจสอบระดับสคีมาในทุก endpoint, นอกเหนือจากแค่รหัสสถานะ
• Mock servers สำหรับการพัฒนาแบบออฟไลน์
• CI pipeline เดียวที่ล้มเหลวเมื่อเกิดการถดถอยทั้ง UI หรือ API
• การดักจับเครือข่ายใน Playwright, การเชื่อมโยง scenario ที่ลึกซึ้งใน Apidog
• ความเป็นเจ้าของที่ชัดเจน: วิศวกร UI เป็นเจ้าของ Playwright specs, วิศวกร API เป็นเจ้าของ Apidog scenarios

เริ่มต้นด้วยการเดินทางที่สำคัญเพียงหนึ่งเดียว เช่น การชำระเงินหรือการลงทะเบียน เชื่อมต่อ Playwright fixture สร้าง Apidog scenario ที่ตรงกัน รันทั้งสองใน CI ขยายจากตรงนั้น ดาวน์โหลด Apidog นำเข้า OpenAPI spec ของคุณ และคุณสามารถมี scenario แรกที่ทำงานได้ในวันนี้

คำถามที่พบบ่อย

ฉันสามารถตรวจสอบ API ใน Playwright tests โดยไม่ใช้ Apidog ได้หรือไม่? ได้ คุณสามารถใช้ request fixture ของ Playwright และเรียกใช้ expect ด้วยตนเอง คุณจะครอบคลุมรหัสสถานะและฟิลด์ body ไม่กี่รายการ สำหรับการตรวจสอบสคีมา, scenarios ที่เชื่อมโยงกัน, mocks และการครอบคลุมเส้นทางข้อผิดพลาดในระดับใหญ่ เครื่องมือเฉพาะเช่น Apidog จะเร็วกว่าและสร้างผลบวกปลอมน้อยลง ดูการเปรียบเทียบ เครื่องมือทดสอบ API สำหรับวิศวกร QA ของเราสำหรับข้อดีข้อเสีย

ฉันจำเป็นต้องมี OpenAPI spec เพื่อใช้การตั้งค่านี้หรือไม่? คุณจำเป็นต้องมีเพื่อให้ได้รับประโยชน์สูงสุด หากไม่มี spec คุณยังคงสามารถรัน Playwright และ Apidog ควบคู่กันได้ แต่คุณจะสูญเสียแหล่งข้อมูลเดียวที่เป็นจริง และต้องดูแลตัวอย่าง payloads ในสองที่ การสร้าง spec จาก routes ที่มีอยู่ใช้เวลาวันหรือสองวัน

ฉันจะจัดการการยืนยันตัวตนในทั้งสองเครื่องมือได้อย่างไร? ใช้ขั้นตอน beforeAll ที่ดึงโทเค็นใหม่จาก endpoint การยืนยันตัวตนของคุณ จากนั้นเก็บไว้ใน Playwright fixture และ Apidog environment variable หมุนเวียนโทเค็นในแต่ละรอบการทดสอบ เพื่อไม่ให้โทเค็นที่เก่าทำให้เกิดความรวน

Apidog scenarios สามารถแทนที่ Playwright ได้ทั้งหมดหรือไม่? ไม่ได้ Apidog เป็นเลิศในด้านเวิร์กโฟลว์ API แต่ไม่ได้เรนเดอร์เบราว์เซอร์ สำหรับการยืนยัน UI (ข้อความที่มองเห็นได้, เลย์เอาต์, โฟลว์การคลิก) คุณยังคงต้องใช้ Playwright เครื่องมือทั้งสองครอบคลุมพื้นผิวที่แตกต่างกัน

จะเกิดอะไรขึ้นหากแบ็กเอนด์ของฉันไม่มีสภาพแวดล้อม staging ที่เสถียร? ใช้ mock server ในตัวของ Apidog มันจะสร้าง mock ที่มีสถานะจาก OpenAPI spec ของคุณในคลิกเดียว โดยคืนค่าการตอบกลับตัวอย่างที่กำหนดไว้ใน spec ชุด Playwright และ Apidog scenarios ของคุณจะรันผ่านกับ mock และคุณจะสลับกลับไปใช้แบ็กเอนด์จริงเมื่อ staging มีสุขภาพดี

ฉันจะรักษา CI ให้รวดเร็วได้อย่างไรเมื่อชุดทดสอบเติบโตขึ้น? แท็กการทดสอบตามลำดับความสำคัญและรันเฉพาะ @smoke ในทุกการ push รัน regression test และ Apidog scenario suite เต็มรูปแบบบน PRs ไปยัง main และตามกำหนดการ nightly กำหนด Playwright ให้ทำงานแบบขนานด้วย workers: 4 และ Apidog scenarios ด้วยแฟล็ก --parallel ของ CLI

ฉันจำเป็นต้องมีแผน Apidog แบบชำระเงินสำหรับ CI หรือไม่? Apidog CLI ทำงานได้ทั้งแบบ local และใน CI โดยไม่จำเป็นต้องมีใบอนุญาตสำหรับแต่ละที่นั่งสำหรับการรัน scenario ตรวจสอบหน้าการกำหนดราคาปัจจุบันก่อนที่จะนำไปใช้ในขนาดใหญ่ แผนฟรีครอบคลุมทีมขนาดเล็กส่วนใหญ่