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

أذكرها وكأنها البارحة، ليلة خميس وكنا على وشك إطلاق تحديث جديد ومهم لأحد عملائنا الكبار. الفريق كله سهران، القهوة ما فارقت مكاتبنا، والأدرينالين في أعلى مستوياته. أجرينا كل الاختبارات المعتادة: اختبارات الوحدة (Unit Tests) كلها خضراء، اختبارات التكامل (Integration Tests) ناجحة، وحتى اختبارات الـ End-to-End الأوتوماتيكية مرت بسلام.

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

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

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

ما هي الاختبارات البصرية التراجعية (Visual Regression Testing)؟

ببساطة يا جماعة، هي عملية أتمتة للعبة “أوجد الفروقات”. الفكرة هي أننا نأخذ “لقطات شاشة” (Screenshots) لواجهات المستخدم في حالتها المثالية السليمة، ونحفظها كـ “خط أساس” أو (Baseline). بعد أي تعديل على الكود، نقوم بأخذ لقطات جديدة لنفس الواجهات، ثم نستخدم أداة خاصة لمقارنة اللقطات الجديدة باللقطات الأساسية، بيكسل ببيكسل.

إذا لم يكن هناك أي اختلاف، فالاختبار ينجح. أما إذا كان هناك اختلاف، حتى لو كان بيكسل واحد، فالاختبار يفشل، وتقوم الأداة بتوليد صورة ثالثة تُظهر لك الفروقات باللون الأحمر. حينها، عليك كـ “مطور” أن تقرر:

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

فكر فيها كشبكة أمان تضمن أن واجهاتك لا تتغير خلسة وبشكل غير متوقع. إنها العين التي لا تنام وتراقب كل بيكسل في تطبيقك.

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

قد يسأل سائل: “يا أبو عمر، ما إحنا عنا Cypress و Selenium وبنعمل E2E tests، ليش وجعة الراس هاي؟”. سؤال وجيه، يا خال. الجواب هو أن هذه الأدوات، على عظمتها، “عمياء” من الناحية البصرية. يمكن لاختبار Cypress أن يؤكد لك أن الزر #add-to-cart-btn موجود في الصفحة (DOM)، وأنه قابل للنقر، وأنه عند النقر عليه ينقلك إلى الصفحة الصحيحة. لكنه لا يعرف، ولن يخبرك أبدًا، ما إذا كان:

• لون الزر قد تغير من الأزرق إلى الأخضر.
• الزر أصبح شفافًا أو مخفيًا بسبب خطأ في z-index.
• حجم الخط داخل الزر كبر فجأة وأصبح النص يخرج من حدوده.
• الزر كله مزاح 50 بيكسل إلى اليمين بسبب تغيير في padding في عنصر أب.

الاختبارات الوظيفية تتأكد من “سلوك” التطبيق، بينما الاختبارات البصرية تتأكد من “مظهر” التطبيق. وكلاهما ضروري لتجربة مستخدم ممتازة.

كيف تبدأ مع الاختبارات البصرية؟ (الأدوات والمنهجية)

الجميل في الموضوع أن السوق مليء بالأدوات الرائعة التي تسهل هذه العملية. دعنا نقسمها لسهولة الفهم.

h3: أدوات مدمجة مع أطر الاختبار الحالية

إذا كنت تستخدم أطر عمل حديثة مثل Playwright أو Cypress، فأنت على بعد خطوات قليلة من تطبيق الاختبارات البصرية.

مثال عملي باستخدام Playwright:

Playwright، من مايكروسوفت، يأتي مع دعم مدمج ورائع للاختبارات البصرية. لنرى كيف يمكننا اختبار صفحتنا الرئيسية:

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

test.describe('Visual Tests for Homepage', () => {

  test('Homepage should remain visually consistent', async ({ page }) => {
    // 1. اذهب إلى الصفحة المطلوبة
    await page.goto('https://your-app.com');

    // 2. انتظر حتى يتم تحميل العناصر المهمة (اختياري لكنه مهم)
    await page.waitForSelector('#main-content');

    // 3. خذ لقطة وقارنها بالـ baseline
    // اسم اللقطة 'homepage-desktop.png'
    await expect(page).toHaveScreenshot('homepage-desktop.png', {
      maxDiffPixels: 100 // السماح بفرق بسيط جدًا لتجنب الفشل بسبب anti-aliasing
    });
  });

});

شرح الكود ببساطة:

1. في المرة الأولى التي تشغل فيها هذا الاختبار، لن يجد Playwright ملف homepage-desktop.png، لذلك سيقوم بإنشائه وحفظه كـ “خط أساس” (Baseline) في مجلد خاص.
2. في كل مرة تالية تشغل فيها الاختبار، سيقوم Playwright بأخذ لقطة جديدة ومقارنتها بالملف المحفوظ.
3. إذا كان هناك اختلاف أكبر من maxDiffPixels، سيفشل الاختبار ويولد لك 3 ملفات: اللقطة الأساسية، اللقطة الجديدة، وصورة الفروقات (diff).

الأمر بهذه السهولة والروعة! يمكنك فعل نفس الشيء تمامًا مع Cypress باستخدام إضافات مثل cypress-image-snapshot.

h3: أدوات ومنصات متخصصة

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

• Percy.io: واحدة من أشهر الأدوات، تتكامل بسهولة مع CI/CD ومعظم أطر الاختبار.
• Applitools: تستخدم الذكاء الاصطناعي (AI) في المقارنة، مما يجعلها أذكى في تجاهل التغييرات الطفيفة (مثل anti-aliasing) والتركيز على التغييرات الحقيقية.
• Chromatic: الخيار الأمثل إذا كنت تستخدم Storybook. إنها مصممة لاختبار المكونات (Components) بشكل معزول.

نصائح من مطبخ أبو عمر 🍳

بعد سنوات من تطبيق هذه التقنية، تعلمت بعض الدروس بالطريقة الصعبة. إليكم خلاصة خبرتي لتجنبوا أخطائي:

1. ابدأ صغيرًا ولكن مهمًا: لا تحاول تغطية 100% من تطبيقك من اليوم الأول، ستصاب بالإحباط. ابدأ بالصفحات والمكونات الأكثر أهمية: الصفحة الرئيسية، صفحة المنتج، عملية الدفع، الأزرار الرئيسية، الهيدر والفوتر.
2. اختبار المكونات أم الصفحات الكاملة؟ افعل الاثنين! استخدم Storybook مع Chromatic لاختبار مكوناتك بشكل معزول وسريع. واستخدم Playwright/Cypress لاختبار صفحات كاملة للتأكد من أن المكونات تتفاعل مع بعضها بشكل صحيح.
3. احذر من المحتوى الديناميكي: الاختبارات البصرية تكره التغيير. إذا كانت صفحتك تعرض تاريخ اليوم، أو قائمة أخبار متغيرة، أو إعلانات، فسيفشل الاختبار في كل مرة. الحل؟
   • البيانات الوهمية (Mocking): الحل الأفضل. اجعل اختباراتك تعمل دائمًا مع مجموعة ثابتة من البيانات الوهمية.
   • إخفاء العناصر (Masking): معظم الأدوات تسمح لك بتحديد مناطق معينة في الصفحة لتجاهلها أثناء المقارنة. استخدم هذه الميزة لإخفاء التواريخ، الصور الرمزية للمستخدمين، أو أي محتوى ديناميكي.
4. اجعلها جزءًا من الـ CI/CD: القوة الحقيقية لهذه الاختبارات تظهر عندما تعمل بشكل تلقائي مع كل Pull Request. هذا يمنع دمج أي تغيير يسبب “علّة بصرية” في الفرع الرئيسي للكود.
5. لا تخف من تحديث الـ Baseline: عملية مراجعة الفروقات وتحديث الـ Baseline هي جزء طبيعي من العمل. عندما تقوم بتغيير مقصود في التصميم، فإن تحديث اللقطة المرجعية هو الإجراء الصحيح.

الخلاصة: نم قرير العين أيها المطور

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

لا تدع “البيكسل الضائع” يفسد عليك يومك أو علاقتك بمديرك. ابدأ اليوم، ولو باختبار مكون واحد فقط. راحة البال التي ستحصل عليها لا تقدر بثمن. يعطيكم العافية! 💪