اختبارات Playwright الخاصة بك، يتحقق منها Delta-QA. سطر واحد لكل صفحة تريد التحقق منها.

ثلاث خطوات في اختباراتك

1. أنشئ مفتاح API في مساحة عمل Delta-QA واحفظه في سرّ ضمن CI. تقرأه الحزمة من DELTAQA_API_KEY؛ ومساحة العمل هي مساحة المفتاح.
2. أضف check حيث يجب أن يتحقق اختبارك من الصفحة: vision.check("Payment"). اسمه يربطه بمرجعه.
3. ادفع التغييرات. في التشغيل الأول، يكون كل اختبار «جديدًا»: تصبح لقطته الأولى المرجع. وفي التشغيل الثاني، إذا لم يتغير الموقع، لا يُبلَّغ عن أي اختلاف.

import { test } from "@playwright/test";
import { Vision } from "@delta-qa/vision";

const vision = new Vision(); // reads DELTAQA_API_KEY

test("Checkout", async ({ page }) => {
  await vision.open(page, { id: "checkout", name: "Checkout" });
  await page.goto("https://shop.example.com/checkout");
  await vision.check("Payment");
  await vision.close(); // fails the test on an unreviewed difference
});

لا تعرض الحزمة إلا الإعدادات التي يطبقها Delta-QA: لا يُقبل أي إعداد بلا أثر. الوسم ووسم المرجع اختياريان؛ وبدونهما تستنتجهما الحزمة.

مرجع واحد لكل فرع، دون دمج تلقائي

• يُستنتج الوسم من فرع git لديك أو من CI، ووسم المرجع من هدف طلب الدمج، وإلا main. يُقارَن الفرع الجديد بـ main منذ تشغيله الأول، وتعرض الدفعة «مقارنة بـ main».
• «سلوك متوقع» يُطبَّق على الوسوم التي تحددها، و«هذا الوسم فقط» افتراضيًا: لا ترى الفروع الأخرى أي تغيير.
• يمكن تصفية سجل الاختبار بحسب البيئة والوسم؛ ويمكن تعيين أي فحص مرجعًا، للوسوم التي تحددها.
• تشكّل اختبارات تشغيل CI واحد دفعة تتشاركها الأجهزة العاملة بالتوازي؛ وتُقرأ قائمة الدفعات كما يُقرأ CI لديك.

أنشئ سيناريوهاتك بوكيل ذكاء اصطناعي: خادم MCP