التحقق من استجابات API في اختبارات بلاي رايت

تنجح اختبارات Playwright الخاصة بك. يتم النقر على زر تسجيل الدخول، وتظهر لوحة التحكم، ويرسم الرسم البياني. ثم يبلغ أحد العملاء عن خطأ: أرقام الرسم البياني خاطئة. تتحقق وتجد أن واجهة برمجة التطبيقات (API) أعادت حالة 200 مع حمولة مشوهة، ولم تلاحظ مجموعتك الشاملة (end-to-end) ذلك أبدًا لأنها تحققت فقط من ظهور وحدات البكسل على الشاشة. هذه هي الفجوة التي لا تستطيع اختبارات المتصفح وحدها سدها، وهنا تصبح تأكيدات واجهة برمجة التطبيقات غير قابلة للتفاوض. تمنحك أدوات مثل Apidog طريقة للتحقق من عقود واجهة برمجة التطبيقات والمخططات ودلالات الاستجابة بنفس الدقة التي تمنحها لتدفقات واجهة المستخدم الخاصة بك، ثم تشغيل كلتا المجموعتين معًا في CI.

ملخص سريع

يمكنك التحقق من واجهات برمجة التطبيقات في اختبارات Playwright من خلال الجمع بين أداة request ومُعترض page.route في Playwright مع سيناريوهات Apidog التي تستخدم نفس مواصفات OpenAPI. شارك الأدوات الثابتة (fixtures) من خلال ملف مواصفات واحد، وتحقق من مخططات الاستجابة في كلا الطبقتين، وقم بتشغيل كلتا المجموعتين في وظيفة CI واحدة بحيث يفشل تغيير العقد بسرعة في أي من المكانين.

مقدمة

يعد Playwright إطار عمل التشغيل الآلي الافتراضي للمتصفح للعديد من الفرق في عام 2026، وتجعل وثائق Playwright اختبار واجهة برمجة التطبيقات يبدو سهلاً: بضع استدعاءات request.get، و expect(response.status()).toBe(200)، وتكون قد انتهيت. تبدأ المشكلة عندما تقوم بتوسيع نطاق ذلك. ينتهي بك الأمر بمئات الاختبارات التي تتحقق من رموز الحالة ولكن ليس من شكل الاستجابة، ولا يوجد مصدر واحد للحقيقة مشترك بين تدفقات المتصفح وتدفقات واجهة برمجة التطبيقات، ولا توجد طريقة لمحاكاة واجهات برمجة التطبيقات دون اتصال عندما يكون الخادم الخلفي بطيئًا أو معطلاً.

الحل بسيط ومباشر. عامل مواصفات OpenAPI الخاصة بك كعقد، وقم بتشغيل استدعاءات request في Playwright ومُعترضات page.route من هذا العقد، وقم بتشغيل مجموعة سيناريوهات Apidog مقابل نفس المواصفات للتحقق العميق من المخطط ومنطق العمل والطلبات المتسلسلة. تحصل على ملاحظات سريعة في CI، وحدود ملكية واضحة بين اختبارات الواجهة الأمامية والواجهة الخلفية، وصفر من الأدوات الثابتة المكررة. إذا كنت ترغب في تثبيت الأداة أولاً، قم بتنزيل Apidog ثم عد؛ تفترض الخطوات أدناه أنها متوفرة محليًا.

إليك ما ستحصل عليه من هذا المنشور: نموذج ذهني واضح لمكان تأكيدات واجهة برمجة التطبيقات في مجموعة Playwright، ونمط request.fixture فعال، وإعداد خطوة بخطوة لمشاركة الأدوات الثابتة بين Playwright و Apidog، ونصائح متقدمة لـ CI والمحاكاة، وجدول مقارنة للبدائل الرئيسية. للحصول على سياق أوسع حول خيارات أدوات الاختبار، راجع وجهة نظرنا حول أدوات اختبار واجهة برمجة التطبيقات لمهندسي ضمان الجودة.

الفجوة بين اختبارات Playwright وتأكيدات واجهة برمجة التطبيقات

يقوم اختبار Playwright النموذجي بتسجيل الدخول، والتنقل إلى صفحة، والتأكيد على أن بعض عناصر واجهة المستخدم مرئية. يخبرك هذا أن التدفق المرئي للمستخدم يعمل. لكنه لا يخبرك شيئًا عن واجهة برمجة التطبيقات (API) التي تقف وراءه. ثلاثة أنماط فشل تتسرب:

أولاً، تراجع شكل الحمولة. تعيد نقطة النهاية 200 مع حقل تم تغيير اسمه من total_count إلى totalCount. قد تقوم واجهة المستخدم بالتحويل ضمنيًا أو عرض صفر. يرى اختبار Playwright الخاص بك رقمًا على الشاشة ويمر.

ثانيًا، انحراف منطق العمل. تطبق نقطة نهاية الخصم خصمًا بنسبة 10 بالمائة بدلاً من 15 بالمائة المتفق عليها. تعرض واجهة المستخدم ما تعيده واجهة برمجة التطبيقات، لذلك يمر الاختبار. يلاحظ فريق الشؤون المالية ذلك فقط، بعد أسابيع.

ثالثًا، تغطية مسار الخطأ. تعمل اختبارات Playwright دائمًا تقريبًا على المسار السعيد (happy path). تحتوي واجهة برمجة التطبيقات الخاصة بك على عشرات الفروع 4xx و 5xx: حدود المعدل، الرموز المميزة منتهية الصلاحية، الفشل الجزئي، تعارضات المعرفية. لا يتم ممارسة أي منها إلا إذا كتبت مجموعة اختبارات API منفصلة.

يمكنك تصحيح بعض هذا عن طريق إضافة استدعاءات request.get داخل مواصفات Playwright الخاصة بك وتأكيد نصوص الاستجابة. هذا يعمل لعدد قليل من نقاط النهاية. ينهار عندما يكون لديك 200 نقطة نهاية وتريد سيناريوهات متسلسلة مثل "إنشاء طلب، جلب طلب، إلغاء طلب، التحقق من رد فعل الويب (webhook) الخاص باسترداد الأموال". Playwright هو إطار عمل لأتمتة المتصفح في المقام الأول؛ لم يتم تصميمه لسير عمل واجهة برمجة التطبيقات ذات الحالة أو بيئة عمل التأكيد على مستوى المخطط. وهنا تكتسب أداة اختبار واجهة برمجة التطبيقات المخصصة قيمتها.

التقسيم الصحيح هو:

• اختبارات Playwright تتحقق من تدفقات واجهة المستخدم، اعتراض الشبكة، وطبقة رقيقة من الفحوصات الأولية لواجهة برمجة التطبيقات (API smoke checks) عند حدود إجراء المستخدم.
• سيناريوهات Apidog تتحقق من توافق المخطط، وسير عمل واجهة برمجة التطبيقات المتسلسل، وتوافق العقد، ومسارات الأخطاء بعمق.

تستهلك كلتا المجموعتين نفس مواصفات OpenAPI بحيث لا يكون لديك أبدًا نسختان من الحقيقة. للحصول على رؤية أعمق حول نهج "العقد أولاً"، يستعرض مقالنا حول سير عمل واجهة برمجة التطبيقات القائمة على التصميم أولاً سبب وجوب أن تكون المواصفات هي الرائدة.

كيفية مشاركة الأدوات الثابتة (fixtures) بين Playwright و Apidog

المصدر الوحيد للحقيقة هو مواصفات OpenAPI الخاصة بك، وعادة ما تكون openapi.yaml أو openapi.json في جذر المستودع. يقرأها Playwright للمساعدات الطلبات المكتوبة (typed request helpers) وحمولات الأمثلة؛ يقوم Apidog باستيرادها مباشرة لملء خطوات السيناريو. كلما أرسل الخادم الخلفي تغييرًا في العقد، تلتقطه كلتا المجموعتين.

ابدأ بمجلد fixtures/ الذي يحتوي على بيانات اختبار قابلة لإعادة الاستخدام: المستخدمين، الرموز المميزة، حمولات العينة. قم بإنشاء ملف 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 من ملف الأدوات الثابتة هذا بدلاً من @playwright/test في كل مواصفة، ولديك apiRequest مكتوب، و authToken جديد، وبيانات sampleOrder جاهزة للاستخدام. ملف order.json هو نفس الحمولة التي يستخدمها Apidog كهيئة مثال لـ POST /orders في سيناريوهاتك. قم بتحريره مرة واحدة، وتتغير كلتا المجموعتين.

بالنسبة لجانب Apidog، افتح المشروع، انقر على "استيراد" (Import)، ووجهه إلى نفس ملف openapi.yaml. يقوم Apidog بإنشاء نقاط النهاية وأمثلة الطلبات ومخططات المعلمات في ثوانٍ. ثم احفظ حمولات أدواتك الثابتة كـ "متغيرات بيئة" (Environment Variables) أو "مجموعات بيانات" (Data Sets) في Apidog:

// 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، تنشر خطوة السيناريو المطابقة نفس الحمولة، ثم تقوم بتشغيل فحص JSON Schema المضمن مقابل مكون Order في openapi.yaml. يمنحك ذلك عمقًا: يتم فحص نوع كل حقل، ويتم التحقق من الحقول المطلوبة، ويتم فرض قيم التعداد. يلتقط Playwright التأكيد الدلالي عالي القيمة (discount_pct: 15)؛ ويلتقط Apidog كل حقل ينحرف، حتى تلك التي نسيت تأكيدها يدويًا. إذا كنت جديدًا في الاختبار الموجه بالمواصفات، فإن شرحنا حول سير عمل واجهة برمجة التطبيقات القائمة على التصميم أولاً يوضح النمط المحيط.

بالنسبة للفرق التي تستخدم Postman بالفعل وتفكر في التبديل، فإن بدائل Postman المستضافة ذاتيًا تغطي آليات الترحيل.

إعداد سير عمل Apidog + Playwright

فيما يلي إعداد نظيف وقابل للتكرار يوصلك من الصفر إلى CI مزدوج المجموعة في حوالي ساعة.

الخطوة 1: مواصفة واحدة تحكمها كلها. ضع openapi.yaml في جذر المستودع. عاملها ككود: مراجعات طلب السحب (PR reviews) مطلوبة، التغييرات الكبيرة تتطلب رفع إصدار رئيسي. إذا لم يكن لديك واحد بعد، فقم بإنشاء مسودة من مساراتك الحالية باستخدام مكون إضافي للإطار (FastAPI، NestJS، وغيرها تصدر OpenAPI أصلاً)، ثم قم بتحريرها يدويًا. يمكن لـ Apidog أيضًا الهندسة العكسية للمواصفات من حركة المرور إذا قمت باستيراد ملف HAR.

الخطوة 2: ربط Playwright. قم بتثبيت Playwright (npm init playwright@latest) وأضف ملف الأدوات الثابتة الموضح أعلاه. أضف سكريبت npm run test:e2e وملف playwright.config.ts يشير إلى بيئة التدريج الخاصة بك. اجعل الاختبارات صغيرة؛ سيناريو واحد لكل مواصفة.

الخطوة 3: إضافة طبقة سيناريو Apidog. داخل مشروع Apidog الخاص بك، قم باستيراد openapi.yaml، ثم قم ببناء سيناريو لكل رحلة مستخدم حاسمة: التسجيل، الدفع، استرداد الأموال، تسليم الويب هوك (webhook)، وما إلى ذلك. كل سيناريو هو تسلسل من استدعاءات API مع تأكيدات متسلسلة. يدعم Apidog متغيرات البيئة، وسكريبتات ما قبل الطلب، وتأكيدات ما بعد الاستجابة. قم بتصدير السيناريو كـ JSON قابل للتشغيل عبر سطر الأوامر (CLI) من خلال Apidog CLI (apidog-cli run scenario.json).

الخطوة 4: اعتراض الشبكة في Playwright. عندما تجلب واجهة المستخدم بيانات لا تريد أن تضربها مباشرة، استخدم page.route للاعتراض والتعطيل (stub). تأتي الاستجابات المعطلة من نفس ملفات الأدوات الثابتة، لذلك يبقى العقد ثابتًا:

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، قم بتشغيل نفس سيناريو GET /orders مقابل الواجهة الخلفية الفعلية أو مقابل خادم وهمي لـ Apidog. نفس الأدوات الثابتة، طبقتان من التحقق.

الخطوة 5: دمج CI. أضف سير عمل 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
  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

فشل أي من الوظيفتين يمنع الدمج. استخدم --reporters junit حتى يقوم GitHub بتعليق التأكيدات الفاشلة مباشرة على طلب السحب (PR). تغطي وثائق GitHub Actions بناء المصفوفات والتخزين المؤقت إذا كنت ترغب في توسيع نطاق ذلك. للفرق التي لا تحتوي على وظيفة ضمان جودة مخصصة، يشرح شرح أداة اختبار واجهة برمجة التطبيقات لمهندسي ضمان الجودة كيفية تعيين ملكية كل مجموعة.

الخطوة 6: اكتشاف الانحراف. قم بجدولة مهمة يومية تقارن ملف openapi.yaml المباشر بالنسخة التي تم تشغيل الاختبارات عليها آخر مرة. إذا تغير نوع حقل ما، يفشل الاختلاف (diff) البناء قبل تشغيل أي اختبارات. هذا يلتقط فئة الأخطاء "200 OK مع حمولة خاطئة" التي بدأنا بها.

تقنيات متقدمة ونصائح احترافية

بعض الحركات التي تؤتي ثمارها بعد تشغيل الإعداد الأساسي.

تثبيت عارض تتبع Playwright. عيّن trace: 'on-first-retry' في playwright.config.ts. عندما يفشل اختبار غير مستقر في CI، تحصل على جدول زمني كامل لاستدعاءات الشبكة، ولقطات DOM، وسجلات وحدة التحكم. ادمجها مع apidog-cli --report html لجانب API. يوضحان معًا ما إذا كانت واجهة المستخدم تعطلت أولاً أم أن API انحرف.

استخدم خوادم Apidog الوهمية للتشغيل دون اتصال. يمكن لـ Apidog تشغيل خادم وهمي من مواصفات OpenAPI الخاصة بك بنقرة واحدة. وجه بيئة التطوير المحلية الخاصة بك إليه عندما يكون فريق الواجهة الخلفية في منتصف عملية النشر أو يتم إعادة تعيين قاعدة بيانات التدريج. تعمل مجموعة Playwright الخاصة بك بشكل أخضر مقابل الخادم الوهمي، وتتحقق سيناريوهات Apidog الخاصة بك من الواجهة الخلفية الحقيقية بالتوازي. لمزيد من المعلومات حول هذا النمط، راجع نظرتنا إلى إنشاء اختبارات واجهة برمجة التطبيقات بمساعدة الذكاء الاصطناعي حيث تلعب المحاكاة دورًا أساسيًا.

حدد عدد المحاولات إلى اثنين. retries: 2 في playwright.config.ts. إذا كان الاختبار يحتاج إلى ثلاث محاولات للمرور، فهو غير مستقر ولديك مشكلة حقيقية. لا تغطِها بـ retries: 5. وينطبق الشيء نفسه على سيناريوهات Apidog: عيّن retry: 1 لكل طلب كحد أقصى.

الفشل عند انحراف المخطط. عندما يكتشف Apidog عدم تطابق في المخطط، اخرج بقيمة غير صفرية بشكل افتراضي. لا تدع تحذيرًا يتسلل. إذا كان يجب عليك السماح بفترة فشل بسيط، قم بتقييده خلف متغير بيئة مثل ALLOW_SCHEMA_DRIFT=true واطلب تعليقًا على طلب السحب (PR) يشرح السبب.

وضع علامات على الاختبارات حسب الأولوية. استخدم test.describe.configure({ mode: 'serial' }) في Playwright للتدفقات ذات الحالة وضع علامات على الآخرين بـ @smoke، @regression، @nightly. قم بتشغيل اختبارات "smoke" على كل دفع (push)، واختبارات الانحدار (regression) على طلبات السحب (PRs) إلى الفرع الرئيسي، واختبارات ليلية عبر مجموعة سيناريوهات Apidog الكاملة. يوفر هذا دقائق CI دون فقدان التغطية.

أخطاء شائعة يجب تجنبها:

• التأكيد على status === 200 فقط. أضف على الأقل فحص حقل واحد في النص الأساسي.
• تشفير رموز الحامل (bearer tokens) في الأدوات الثابتة (fixtures). استخدم beforeAll لجلب رموز جديدة.
• السماح لـ Playwright و Apidog باستيراد ملفات أدوات ثابتة مختلفة. مصدر واحد، نقطة.
• تجاهل Apidog CLI في CI لأن "أداة واجهة المستخدم جيدة بما فيه الكفاية". إنها ليست كذلك؛ CLI هو ما يفشل البناء.
• معاملة أدوات page.route المؤقتة كبديل لاختبارات API الحقيقية. إنها للعزل، وليس للتغطية.

بالنسبة للفرق التي تقوم بإنشاء اختبارات باستخدام الذكاء الاصطناعي، يغطي دليل كيفية اختبار واجهة برمجة تطبيقات وكلاء الذكاء الاصطناعي الحالات غير الحتمية التي تتطلب عناية إضافية.

البدائل ومقارنة الأدوات

يمكن للعديد من مجموعات الأدوات التحقق من واجهات برمجة التطبيقات جنبًا إلى جنب مع اختبارات المتصفح. إليك كيفية مقارنة الخيارات الرئيسية.

إذا كنت قادمًا من أدوات عصر SOAP الأقدم، فإن مقالاتنا حول بدائل سكريبت SoapUI Groovy و بدائل ReadyAPI تغطي مسار الترحيل. لسير العمل المحلي أولاً، تستحق ملحقات REST client لـ VSCode القراءة.

يفوز الاقتران بين Playwright و Apidog للفرق التي لديها مواصفات OpenAPI، وتشحن خدمات متعددة، وتريد خط أنابيب CI واحدًا يلتقط كلاً من تراجعات واجهة المستخدم وواجهة برمجة التطبيقات دون دفع مقابل مقعدين لـ SaaS لكل مهندس.

حالات الاستخدام في العالم الحقيقي

الخروج من التجارة الإلكترونية. يدير فريق التجزئة اختبارات Playwright لتدفق "من سلة التسوق إلى التأكيد" وسيناريوهات Apidog لسلسلة واجهة برمجة تطبيقات نية الدفع، وفحص الاحتيال، وتقليل المخزون. عندما قام بوابة الدفع بتبديل حقل استجابة من error_code إلى errorCode، التقطها Apidog في 90 ثانية؛ كان Playwright سيظهر شاشة "فشل الدفع" عامة ويستغرق ساعات للتحقق من المشكلة.

لوحة تحكم SaaS مع بيانات الرسم البياني. يتحقق منتج تحليلات B2B من عرض واجهة المستخدم باستخدام لقطات Playwright ويستخدم Apidog للتأكيد على أن نقاط نهاية التجميع (aggregation endpoints) تعيد المجاميع والنسب المئوية والسلاسل المحددة زمنيًا الصحيحة. تم اكتشاف خطأ حيث أسقطت نقطة نهاية زمن الوصول p99 القيم الشاذة بصمت في طبقة API؛ بينما كان الرسم البياني يبدو جيدًا.

سير العمل المدفوع بالويب هوك. يستخدم فريق التكنولوجيا المالية Playwright للبوابة الموجهة للمستخدم وسيناريوهات Apidog لتسليم الويب هوك (webhook delivery)، ومنطق إعادة المحاولة، والمعرفية (idempotency). يتحقق سكريبت Apidog من رفض معرفات الويب هوك المكررة، ومن صحة التوقيعات، وأن نافذة الاتساق النهائي (eventual-consistency window) أقل من 30 ثانية.

الخلاصة

يتفوق Playwright في تدفقات المتصفح. لكنه لم يُبنَ لاختبار واجهة برمجة التطبيقات (API) بشكل عميق. يمنحك إقرانه بـ Apidog ما يلي:

• مواصفة OpenAPI واحدة كعقد بين المجموعتين.
• أدوات ثابتة (fixtures) مشتركة لضمان عدم انحراف بيانات الاختبار أبدًا.
• التحقق على مستوى المخطط لكل نقطة نهاية، بما يتجاوز رموز الحالة وحدها.
• خوادم وهمية للتطوير دون اتصال.
• خط أنابيب CI واحد يفشل عند وجود تراجعات في واجهة المستخدم أو واجهة برمجة التطبيقات.
• اعتراض الشبكة في Playwright، سلاسل سيناريوهات عميقة في Apidog.
• ملكية واضحة: مهندسو واجهة المستخدم يمتلكون مواصفات Playwright، مهندسو واجهة برمجة التطبيقات يمتلكون سيناريوهات Apidog.

ابدأ برحلة حرجة واحدة، مثل عملية الدفع أو التسجيل. قم بتوصيل أداة Playwright الثابتة، وقم بإنشاء سيناريو Apidog المطابق، وقم بتشغيلهما معًا في CI. ثم توسع من هناك. قم بتنزيل Apidog، استورد مواصفات OpenAPI الخاصة بك، ويمكنك تشغيل السيناريو الأول اليوم.

الأسئلة الشائعة

هل يمكنني التحقق من واجهات برمجة التطبيقات في اختبارات Playwright بدون Apidog؟ نعم، باستخدام أداة request الثابتة في Playwright واستدعاءات expect اليدوية. ستغطي رموز الحالة وبعض حقول النص الأساسي. للتحقق من المخطط، والسيناريوهات المتسلسلة، والمحاكاة، وتغطية مسار الأخطاء على نطاق واسع، فإن أداة مخصصة مثل Apidog أسرع وتنتج عددًا أقل من الإيجابيات الخاطئة. راجع مقارنة أدوات اختبار واجهة برمجة التطبيقات لمهندسي ضمان الجودة للتعرف على المقايضات.

هل أحتاج إلى مواصفات OpenAPI لاستخدام هذا الإعداد؟ نعم، تحتاج إلى واحدة للحصول على الفائدة الكاملة. بدون مواصفات، لا يزال بإمكانك تشغيل Playwright و Apidog جنبًا إلى جنب، لكنك تفقد المصدر المشترك للحقيقة وعليك صيانة حمولات الأمثلة في مكانين. يستغرق إنشاء مواصفات من المسارات الموجودة يومًا أو يومين.

كيف أتعامل مع المصادقة عبر كلتا الأداتين؟ استخدم خطوة beforeAll تجلب رمزًا مميزًا جديدًا من نقطة نهاية المصادقة الخاصة بك، ثم قم بتخزينه في أداة Playwright الثابتة ومتغير بيئة Apidog. قم بتدوير الرموز المميزة لكل تشغيل اختبار حتى لا تتسبب الرموز المميزة القديمة في عدم الاستقرار.

هل يمكن لسيناريوهات Apidog أن تحل محل Playwright بالكامل؟ لا. Apidog ممتاز في سير عمل واجهة برمجة التطبيقات ولكنه لا يعرض المتصفحات. لتأكيدات واجهة المستخدم (النص المرئي، التخطيط، تدفقات النقر) لا يزال يتعين عليك استخدام Playwright. تغطي الأداتان أسطحًا مختلفة.

ماذا لو لم يكن لدي الواجهة الخلفية بيئة تدريج مستقرة؟ استخدم خادم Apidog الوهمي المدمج. يقوم بتشغيل خادم وهمي ذو حالة من مواصفات OpenAPI الخاصة بك بنقرة واحدة، ويعيد استجابات أمثلة محددة في المواصفات. تعمل مجموعة Playwright الخاصة بك وسيناريوهات Apidog بشكل أخضر مقابل الخادم الوهمي، وتعود إلى الواجهة الخلفية الحقيقية عندما تكون بيئة التدريج صحية.

كيف أحافظ على سرعة CI مع نمو المجموعة؟ ضع علامات على الاختبارات حسب الأولوية وقم بتشغيل @smoke فقط على كل دفع. قم بتشغيل مجموعة اختبارات الانحدار الكاملة وسيناريوهات Apidog على طلبات السحب (PRs) إلى الفرع الرئيسي وفي جدول زمني ليلي. قم بموازاة Playwright باستخدام workers: 4 وسيناريوهات Apidog باستخدام علامة --parallel الخاصة بـ CLI.

هل أحتاج إلى خطة Apidog مدفوعة لـ CI؟ يعمل Apidog CLI محليًا وفي CI دون ترخيص مقاعد لتنفيذ السيناريوهات. تحقق من صفحة الأسعار الحالية قبل الاعتماد على نطاق واسع. تغطي الطبقة المجانية معظم الفرق الصغيرة.