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

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

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

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

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

شو اللي صاير؟ كيف كل الاختبارات نجحت وطلعنا بهيك مصيبة؟ بعد ساعات من التوتر والبحث، اكتشفنا السبب: تغيير بسيط في ملف CSS مركزي، عمله زميل جديد بنية حسنة عشان يصلح شغلة صغيرة في صفحة ثانوية، لكنه بدون قصد “خرب الدنيا” في باقي التطبيق. الاختبارات الوظيفية ما مسكت الخطأ، لأن الأزرار لسا “بتشتغل” والقوائم لسا “بتفتح”، لكن شكلها كان كارثي.

هذاك اليوم كان جحيم حقيقي، لكن من رحم المعاناة يولد الأمل. هذاك اليوم هو اللي خلانا نكتشف ونتعمق في عالم “اختبار الانحدار البصري”، السلاح السري اللي صار جزء لا يتجزأ من أي مشروع بنشتغله. واليوم، بدي أشارككم هاي الخبرة، عشان ما تقعوا في نفس الحفرة اللي وقعنا فيها.

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

ببساطة شديدة، تخيل إنك بتلعب لعبة “اوجد الفروقات” بين صورتين. اختبار الانحدار البصري هو النسخة المؤتمتة والذكية من هاي اللعبة لواجهة المستخدم (UI) تبعتك.

الفكرة هي كالتالي:

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

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

لماذا لا تكفي الاختبارات التقليدية (الوظيفية)؟

زي ما صار معنا في قصتي، الاختبارات الوظيفية (Functional Tests) ممتازة ومهمة جداً، لكن تركيزها مختلف. هي بتجاوب على سؤال: “هل الميزة تعمل؟”.

• هل عند الضغط على زر “إضافة للسلة”، يتم إضافة المنتج؟
• هل عند إدخال اسم مستخدم وكلمة مرور خاطئة، تظهر رسالة خطأ؟

لكنها عمياء تماماً عن الجانب البصري. هي ما بتجاوب على أسئلة مثل:

• هل زر “إضافة للسلة” لونه أخضر وحجمه مناسب؟
• هل رسالة الخطأ ظاهرة بشكل واضح وليست مخفية خلف عنصر آخر؟
• هل تغير CSS بسيط أدى إلى تداخل كل عناصر الصفحة الرئيسية؟

الاختبارات الوظيفية بتضمن لك إن “الماكينة شغالة”، لكن اختبار الانحدار البصري بيضمن لك إن “شكل الماكينة” سليم ومرتب وجذاب للمستخدم. والاثنان يكملان بعضهما البعض.

كيف يعمل اختبار الانحدار البصري؟ (آلية العمل)

العملية بتمر بثلاث مراحل رئيسية، وهي بسيطة ومباشرة.

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

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

المرحلة الثانية: التشغيل والمقارنة

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

المرحلة الثالثة: مراجعة الفروقات

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

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

عندها، عليك أن تقرر:

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

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

الحمد لله، السوق مليء بالأدوات الرائعة التي تسهل هذه العملية. بعضها خدمات سحابية مدفوعة مثل Percy و Applitools، وبعضها مكتبات مفتوحة المصدر يمكنك دمجها في مشروعك. من أفضل الأدوات الحديثة التي توفر هذه الميزة بشكل مدمج هي Playwright.

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

Playwright هي أداة أتمتة متكاملة من مايكروسوفت، واختبار اللقطات (Snapshot Testing) جزء أساسي منها. لنرى كيف يمكننا استخدامها.

لنفترض أن لدينا زر بسيط في صفحة HTML ونريد التأكد من أن شكله لا يتغير عن طريق الخطأ.

أولاً، نكتب الاختبار. سيكون الملف باسم `button.spec.ts`:

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

test.describe('Homepage Button', () => {
  test('should look the same as the baseline', async ({ page }) => {
    // 1. اذهب إلى الصفحة التي تحتوي على الزر
    await page.goto('http://localhost:3000/my-page');

    // 2. حدد الزر الذي تريد اختباره
    const myButton = page.locator('#submit-button');

    // 3. التقط لقطة شاشة للزر وقارنها بالمرجع
    // في المرة الأولى، سيقوم هذا السطر بإنشاء اللقطة المرجعية
    // في المرات التالية، سيقوم بالمقارنة
    await expect(myButton).toHaveScreenshot('submit-button.png');
  });
});

التشغيل الأول (لإنشاء المرجع):

عندما تشغل هذا الاختبار لأول مرة، سيفشل مع رسالة تقول “A new snapshot was generated”. هذا طبيعي تماماً. ستجد الآن ملف صورة جديد باسم `submit-button.png` في مجلد اللقطات. هذه هي لقطتك المرجعية.

التشغيل الثاني (بعد التغيير):

لنفترض الآن أن مطوراً قام بتغيير لون الزر في ملف الـ CSS من الأزرق إلى الأحمر. عندما يتم تشغيل الاختبار مرة أخرى، سيقوم Playwright بالآتي:

1. يلتقط صورة جديدة للزر (الذي أصبح أحمر).
2. يقارنها بالصورة المرجعية المخزنة (الزر الأزرق).
3. يكتشف الاختلاف، ويفشل الاختبار.
4. يولد تقريراً يوضح لك الصور الثلاث: المرجعية، الحالية، والفرق بينهما.

بهذه البساطة، تكون قد أمسكت بخطأ بصري قبل أن يصل للمستخدم!

نصائح من مطبخ أبو عمر (خبرتي الشخصية)

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

• ابدأ صغيراً ومستهدفاً: لا تحاول تغطية كل بكسل في تطبيقك من اليوم الأول. ابدأ بالـ “جواهر”: المكونات القابلة لإعادة الاستخدام (الأزرار، حقول الإدخال)، والصفحات الحرجة (تسجيل الدخول، الدفع، لوحة التحكم الرئيسية).
• تعامل مع المحتوى الديناميكي بذكاء: ماذا عن التواريخ، أو أسماء المستخدمين، أو العدادات التي تتغير؟ معظم الأدوات تسمح لك بـ “إخفاء” (Masking) مناطق معينة في الشاشة قبل التقاط الصورة. في Playwright، يمكنك فعل ذلك بسهولة:

  
  await expect(page).toHaveScreenshot({ 
    mask: [page.locator('#dynamic-clock')] 
  });
          

  هذا يخبر الأداة بتجاهل أي تغييرات في العنصر المحدد.

• احذر من “عتبة الحساسية” (Threshold): بعض الأدوات تسمح لك بتعيين نسبة مئوية من الاختلاف المسموح به لتجنب الفشل بسبب اختلافات طفيفة في عرض الخطوط بين الأنظمة (anti-aliasing). استخدم هذه الميزة بحذر شديد، “لا ترخي الحبل على الآخر”، لأنك قد تفوت أخطاء حقيقية. الأفضل دائماً أن يكون Threshold يساوي صفراً، وأن تحل المشاكل الأساسية.
• الدمج في الـ CI/CD هو سر القوة: القيمة الحقيقية تظهر عندما تكون هذه الاختبارات جزءاً من عملية البناء والنشر التلقائية (CI/CD pipeline). في كل مرة يتم فيها تقديم طلب دمج (Pull Request)، تعمل الاختبارات تلقائياً وتخبرك إذا كان هناك أي انحدار بصري. هذا يمنع الأخطاء من الوصول إلى الفرع الرئيسي من الأساس.
• التنظيم هو المفتاح: مع نمو مشروعك، سينمو عدد لقطات الشاشة. تأكد من تسمية اختباراتك ولقطاتك بأسماء واضحة وذات معنى. `login-form-error-state.png` أفضل بألف مرة من `test1-snap.png`.

الخلاصة والنصيحة الأخيرة 🚀

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

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

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

بالتوفيق!