أتمتة Visual Regression Testing بـ Playwright — امسك تغييرات الـ UI قبل الـ Deploy
لو غيّرت padding في مكون Button وعندك 40 صفحة بتستخدمه، الـ QA ما يقدرش يجرّب الـ 40 صفحة يدويًا في كل PR. Visual Regression Testing مع Playwright بياخد screenshot لكل صفحة قبل وبعد التغيير، يقارنهم بيكسل بيكسل، ويفشل الـ PR لو في اختلاف. النتيجة: 0 visual bugs توصل الإنتاج، بتكلفة 12 دقيقة إعداد أول مرة وبتكلفة 0 دولار شهريًا.
المشكلة باختصار
الـ unit tests بتتأكد إن الـ function بترجّع القيمة الصح، والـ e2e tests بتتأكد إن الزر لمّا يتضغط بيحصل login. لكن ولا واحد فيهم بيشوف الـ UI نفسه. لو حد عدّل CSS في Tailwind config وخلّى الـ font size 14px بدل 16px، كل الاختبارات هتعدي والموقع هيبقى شكله غلط.
الطريقة الشائعة: QA بيفتح 5 صفحات يدويًا ويتطمن. المشكلة: في مشروع متوسط فيه 50-80 صفحة، ده بياخد 3 ساعات لكل PR وبيفوّت تغييرات صغيرة مش واضحة للعين.
الفكرة بمثال بسيط جدًا قبل التقنية
تخيّل إن عندك صورتين لنفس الشارع، واحدة من السنة اللي فاتت وواحدة من النهارده. لو حطيت الصورتين فوق بعض وشفت فيه محل جديد مفتوح، ده بالظبط اللي بيعمله الـ visual regression testing — بس مع صفحات الويب. بياخد صورة "بيسلاين" (baseline) من الـ UI، وبعدين لمّا تعمل تغيير، بياخد صورة جديدة ويحطّها فوق القديمة. لو في بيكسل واحد اختلف، بيقولّك.
بالمفهوم العلمي: الـ visual regression testing هو أسلوب اختبار بيعتمد على خوارزميات مقارنة الصور (image diffing algorithms) زي pixelmatch، بيحسب نسبة البيكسلات المختلفة بين صورتين مرجعيتين، ولو النسبة دي تجاوزت عتبة محددة (threshold) بيعتبر الاختبار فاشل. الـ Playwright بيستخدم pixelmatch داخليًا.
إعداد Playwright في أقل من 3 دقايق
افتح المشروع وشغّل الأمر ده:
npm init playwright@latest
هيسألك عن TypeScript ولا JavaScript، وعن مجلد الاختبارات. خليه الـ defaults. بعدها افتح playwright.config.ts وعدّل الـ expect section:
import { defineConfig, devices } from '@playwright/test';
export default defineConfig({
testDir: './tests',
expect: {
toHaveScreenshot: {
maxDiffPixels: 100,
threshold: 0.2,
},
},
projects: [
{
name: 'chromium',
use: { ...devices['Desktop Chrome'] },
},
],
use: {
baseURL: 'http://localhost:3000',
},
});
