واجهاتي كانت تتكسر بصمت: كيف أنقذني ‘الاختبار البصري الانحداري’ من جحيم الأخطاء المرئية؟

يا جماعة الخير، السلام عليكم ورحمة الله وبركاته، معكم أخوكم أبو عمر.

خلوني أحكي لكم قصة صارت معي قبل كم سنة، قصة علّمتني درس ما بنساه. كنا في الفريق شغالين على تحديث كبير لمنصة تجارة إلكترونية. سهرنا ليالي، كتبنا كود، عملنا اختبارات وحدة (Unit Tests) واختبارات تكامل (Integration Tests)، وكل شي كان يبدو “تمام التمام”. كل الإشارات خضراء، والمدير الفني مبسوط، والكل بستنى إطلاق الميزات الجديدة.

ضغطنا على زر النشر (Deploy) في ليلة خميس، ورحنا على بيوتنا مرتاحين البال، نحلم بنجاح الإطلاق. صحيت ثاني يوم الصبح على صوت تلفوني برن بشكل هستيري. على الخط كان مدير التسويق، وصوته فيه نبرة ذعر: “أبو عمر! شو القصة؟ المبيعات شبه متوقفة من مبارح بالليل! في مصيبة صايرة!”.

قلبي وقع في رجلي. فتحت اللابتوب بسرعة البرق، ودخلت على الموقع. كل شي شغال، المنتجات موجودة، بتقدر تضيفها على السلة… لكن لحظة! وين زر “إتمام الشراء” في صفحة الدفع على الموبايل؟ بعد شوية بحث وتحليل، اكتشفنا الكارثة: تحديث بسيط في ملف CSS مشترك، كان الهدف منه تعديل بسيط في الهامش (margin)، تسبب في أن زر “إتمام الشراء” الحيوي صار مختفي تحت عنصر ثاني على الشاشات الصغيرة. كان موجود، لكن غير مرئي! كل اختباراتنا الآلية نجحت لأن الزر كان موجوداً في الـ DOM، لكنها عمياء، لا “ترى” الواجهة كما يراها المستخدم.

هذاك اليوم، أدركت أننا كنا نبني بيتاً قوياً لكن بواجهة زجاجية هشة، تتكسر مع كل نسمة هواء دون أن نشعر. ومن هنا بدأت رحلتي مع ما يسمى بـ “الاختبار البصري الانحداري” (Visual Regression Testing)، الدرع الذي يحمي واجهاتنا من هذه الكوارث الصامتة.

ما هو الاختبار البصري الانحداري (Visual Regression Testing)؟

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

الفكرة قائمة على المقارنة بالصور (Screenshots):

1. اللقطة المرجعية (Baseline): في المرة الأولى، تقوم الأداة بأخذ “لقطة شاشة” لكل مكون أو صفحة تريد اختبارها. هذه الصور تصبح هي “الحقيقة” أو المرجع المعتمد.
2. المقارنة: بعد أي تعديل على الكود، تقوم الأداة بتشغيل الاختبارات مرة أخرى وأخذ لقطات شاشة جديدة.
3. كشف الاختلافات: تقارن الأداة بين الصور الجديدة والصور المرجعية بكسل ببكسل. إذا وجدت أي اختلاف، يفشل الاختبار ويتم إعلامك فوراً، مع إظهار صورة توضح لك الفروقات بالضبط.

بهذه الطريقة، لن يفلت منك أي تغيير مرئي غير مقصود، سواء كان زراً تحرك من مكانه، أو لوناً تغير، أو خطاً اختلف حجمه.

لماذا الاختبارات التقليدية لا تكفي؟

قد يقول قائل: “يا أبو عمر، ما احنا عنا اختبارات شاملة!”. صحيح، ولكن لكل نوع من الاختبارات مجاله الذي يغطيه، والاختبارات التقليدية لديها نقاط عمياء واضحة عندما يتعلق الأمر بالواجهة المرئية.

محدودية اختبارات الوحدة (Unit Tests)

هذه الاختبارات تتأكد من أن “وحدة” صغيرة من الكود (مثل دالة JavaScript) تعمل كما هو متوقع. هي تتأكد من المنطق البرمجي. يمكن لدالة `getUserData()` أن تعيد بيانات المستخدم بشكل صحيح 100%، لكن هذا لا يضمن أن الـ CSS سيعرض اسم المستخدم وصورته بشكل جميل ومتناسق.

قصور اختبارات التكامل والـ E2E

اختبارات الـ End-to-End (مثل Cypress أو Playwright) تحاكي سلوك المستخدم. هي تتأكد من أن “التدفق” يعمل. مثلاً، “هل عند الضغط على زر ‘إضافة للسلة’، تتم إضافة المنتج فعلاً؟”. هذه الاختبارات لا تهتم إذا كان الزر لونه أحمر بدلاً من أزرق، أو إذا كان نصفه مخفياً. طالما أنها تستطيع “إيجاد” الزر في بنية الصفحة (DOM) والضغط عليه، سيمر الاختبار بنجاح.

عبء الاختبار اليدوي

الاعتماد على العنصر البشري لمراجعة كل شاشات التطبيق بعد كل تحديث هو أمر غير عملي ومكلف جداً. إنه بطيء، ممل، وعرضة للخطأ البشري. “مش منطق يا جماعة” أن نطلب من شخص مراجعة 50 صفحة على 3 أحجام شاشات مختلفة مع كل Pull Request. الأتمتة هنا ليست رفاهية، بل ضرورة.

كيف يعمل الاختبار البصري؟ رحلة من ثلاث خطوات

آلية العمل بسيطة ومباشرة وتتلخص في ثلاث مراحل رئيسية.

الخطوة الأولى: إنشاء اللقطات المرجعية (Baseline Snapshots)

عند تشغيل اختباراتك البصرية لأول مرة، لا يوجد شيء لمقارنتها به. لذلك، ستقوم الأداة بأخذ لقطات شاشة للصفحات والمكونات التي حددتها وحفظها في مجلد خاص (مثلاً `__screenshots__`). هذه هي النسخة “الذهبية” التي ستتم المقارنة معها مستقبلاً. هذه الخطوة تتطلب مراجعة يدوية للتأكد من أن اللقطات الأولية سليمة وخالية من الأخطاء.

الخطوة الثانية: التشغيل والمقارنة (Run and Compare)

الآن، لنفترض أنك قمت بتعديل بعض ملفات الـ CSS. عند تشغيل الاختبارات مرة أخرى (عادةً كجزء من عملية الـ CI/CD)، ستقوم الأداة بتكرار نفس الخطوات وأخذ لقطات جديدة. ثم تبدأ عملية المقارنة الدقيقة بين كل لقطة جديدة واللقطة المرجعية المقابلة لها.

الخطوة الثالثة: المراجعة والتحديث (Review and Update)

هنا يظهر سحر الموضوع. إذا كان هناك اختلاف، سيفشل الاختبار. وستقوم الأداة بإنشاء تقرير مفصل، يعرض لك ثلاث صور:

• الصورة المرجعية (Baseline).
• الصورة الجديدة (Actual).
• صورة الفروقات (Diff)، وهي صورة تسلط الضوء باللون الأحمر على الأماكن التي تغيرت بالضبط.

أمامك الآن قرار واضح:

1. هل هذا التغيير خطأ (Bug)؟ إذاً، عليك العودة للكود وإصلاحه.
2. هل هذا التغيير مقصود (Intended Change)؟ مثلاً، قمت بتغيير تصميم زر بشكل متعمد. في هذه الحالة، تقوم بتنفيذ أمر بسيط يخبر الأداة بتحديث الصورة المرجعية لتصبح هي الصورة الجديدة.

لنطبق عملياً: الاختبار البصري باستخدام Playwright

دعونا نأخذ مثالاً عملياً باستخدام أداة Playwright الرائعة من مايكروسوفت، والتي تأتي مع دعم مدمج للاختبار البصري، مما يجعل العملية سهلة جداً.

1. تجهيز البيئة

أولاً، تأكد من أن لديك Playwright مثبتاً في مشروعك.

npm init playwright@latest

2. كتابة أول اختبار بصري

لنكتب اختباراً بسيطاً يأخذ لقطة شاشة للصفحة الرئيسية لموقع Playwright نفسه. أنشئ ملفاً جديداً باسم `visual.spec.ts`:

import { test, expect } from '@playwright/test';

test('example test', async ({ page }) => {
  // اذهب إلى الصفحة المطلوبة
  await page.goto('https://playwright.dev');

  // هذا هو السطر السحري!
  // سيقوم بأخذ لقطة شاشة ومقارنتها بالمرجع
  await expect(page).toHaveScreenshot('landing-page.png');
});

عند تشغيل هذا الاختبار لأول مرة، سيفشل مع رسالة تخبرك بأنه لا توجد لقطة مرجعية. لتحديثها، نستخدم الأمر:

npx playwright test --update-snapshots

هذا الأمر سيقوم بإنشاء اللقطة المرجعية `landing-page.png-snapshots` داخل مجلد الاختبارات.

3. مشاهدة الاختبار وهو يفشل

الآن، لنقم بمحاكاة تغيير غير مقصود. سنستخدم قدرات Playwright لتعديل الصفحة قبل أخذ اللقطة. سنقوم بإخفاء شعار Playwright:

import { test, expect } from '@playwright/test';

test('example test', async ({ page }) => {
  await page.goto('https://playwright.dev');

  // محاكاة تغيير غير مقصود: إخفاء الشعار
  await page.evaluate(() => {
    const logo = document.querySelector('.navbar__brand');
    if (logo) {
      (logo as HTMLElement).style.visibility = 'hidden';
    }
  });

  // الآن، شغل الاختبار كالعادة
  await expect(page).toHaveScreenshot('landing-page.png');
});

عند تشغيل الاختبار الآن (`npx playwright test`)، سيفشل، وستجد في مخرجات الاختبار تقريراً يوضح لك بالضبط أين حدث الاختلاف (مكان الشعار المختفي).

4. التعامل مع العناصر الديناميكية

مشكلة شائعة هي المحتوى المتغير مثل التواريخ، الإعلانات، أو الأنيميشن. هذا يسبب فشل الاختبارات بشكل مستمر. Playwright يقدم حلولاً رائعة:

• إخفاء العناصر (Masking): يمكنك إخبار Playwright بتغطية مناطق معينة بلون ثابت قبل المقارنة.
• التحكم في الأنيميشن: يمكنك تعطيل الـ CSS animations و transitions.

مثال على إخفاء عنصر ديناميكي:

test('test with dynamic data', async ({ page }) => {
  await page.goto('https://example.com');

  // لنفترض أن هناك عنصر له id="user-last-login" يعرض تاريخاً متغيراً
  const lastLoginElement = page.locator('#user-last-login');

  // قم بإخفاء هذا العنصر قبل أخذ اللقطة
  await expect(page).toHaveScreenshot('profile-page.png', {
    mask: [lastLoginElement]
  });
});

نصيحة من أبو عمر 💡

ابدأ صغيراً! لا تحاول تطبيق الاختبار البصري على كل تطبيقك دفعة واحدة. ابدأ بالصفحات والمكونات الأكثر أهمية وحساسية للتغيير: الهيدر، الفوتر، صفحة الدفع، المكونات الرئيسية في الـ Design System الخاص بك. ثم توسع تدريجياً. هذا يسمى “نهج الزاوية الآمنة”.

نصائح من خبرة أبو عمر لتطبيق ناجح

• اجعل اختباراتك مستقرة: قبل أخذ لقطة الشاشة، تأكد من أن الصفحة قد انتهت من التحميل بالكامل، وأن كل الصور والخطوط قد ظهرت. استخدم `waitFor` للتأكد من استقرار الواجهة.
• استخدم عتبة الاختلاف (Threshold) بحذر: تسمح لك معظم الأدوات بتحديد نسبة اختلاف مقبولة (مثلاً 0.1%). هذا مفيد للتعامل مع الفروقات الطفيفة في عرض الخطوط (anti-aliasing) بين أنظمة التشغيل المختلفة. لكن لا ترفع هذه النسبة كثيراً حتى لا تفوتك أخطاء حقيقية.
• التكامل مع CI/CD هو القوة الحقيقية: قم بإعداد الاختبارات البصرية لتعمل تلقائياً مع كل Pull Request. هذا ينشئ شبكة أمان تمنع دمج أي تغيير يكسر الواجهة المرئية في الفرع الرئيسي.
• إدارة اللقطات المرجعية: تعامل مع مجلد اللقطات المرجعية كجزء من الكود. قم بعمل commit له في Git. بعض الفرق تستخدم Git LFS (Large File Storage) لإدارة هذه الصور بكفاءة، خاصة في المشاريع الكبيرة.

الخلاصة: درعك الواقي من الكوارث البصرية 🛡️

في عالم تطوير الواجهات الأمامية سريع التغير، لم يعد كافياً أن “تعمل” الميزات، بل يجب أن “تبدو” صحيحة أيضاً. الاختبار البصري الانحداري ليس مجرد أداة إضافية، بل هو تغيير في العقلية، هو اعتراف بأن تجربة المستخدم المرئية لا تقل أهمية عن المنطق البرمجي.

منذ تلك الحادثة، أصبحت الاختبارات البصرية جزءاً لا يتجزأ من أي مشروع أعمل عليه. لقد منحتني وفريقي الثقة لإجراء تعديلات وتحسينات كبيرة (Refactoring) على الـ CSS دون خوف من كسر شيء ما في زاوية منسية من التطبيق.

نصيحتي الأخيرة لك: لا تترك واجهاتك تتكسر بصمت. أعطها صوتاً، أعطها عيوناً ترقبها. الاختبار البصري هو تلك العيون التي لا تغفل ولا تمل. ابدأ اليوم، ولو باختبار مكون واحد، وستشكر نفسك في المستقبل. بالتوفيق يا أبطال! 🚀