Visual Testing في GitHub Actions: أتمتة الاختبار البصري في Pipeline CI/CD
الاختبار البصري الآلي (visual testing) هو ممارسة تحقق تعتمد على التقاط لقطات شاشة لواجهة ويب في مراحل مختلفة من التطوير ومقارنتها تلقائياً لاكتشاف الانحدارات الرسومية غير المقصودة.
أصبح GitHub Actions المعيار الفعلي لـ CI/CD في منظومة GitHub. سير عمله بصيغة YAML قوية، وسوق الإجراءات غني، والتكامل مع pull requests سلس. للأتمتة التقليدية — البناء، الاختبارات الوحدوية، التدقيق، النشر — هو خيار ممتاز.
لكن عندما يتعلق الأمر بالاختبار البصري، تتعقد الأمور. ليس لأن GitHub Actions محدود — فهو runner CI مثل أي آخر — بل لأن الاختبار البصري في بيئة CI يطرح تحديات تقلل معظم الفرق من شأنها. يفصّل هذا المقال المقاربات المتاحة، والمزالق الحقيقية، وكيفية الحصول على pipeline اختبار بصري موثوق في GitHub Actions.
لماذا الاختبار البصري في CI أعقد مما يبدو
تنفيذ الاختبارات الوحدوية في CI أمر متوقع. الشيفرة حتمية. النتيجة ثنائية: تنجح أو تفشل. أما الاختبار البصري فيعمل في مجال تكون فيه الحتمية وهماً.
مشكلة العرض غير الحتمي
لقطة شاشة مأخوذة على جهاز التطوير الخاص بك ولقطة شاشة مأخوذة على runner GitHub Actions لن تكونا متطابقتين، حتى مع نفس المتصفح ونفس الدقة. الأسباب متعددة:
الخطوط. runners Ubuntu في GitHub Actions لا تحتوي على نفس الخطوط الموجودة في macOS المحلي. خط بديل مختلف يمكن أن يزيح النص ببضع بكسلات — وهذا كافٍ لإفشال مقارنة بكسل ببكسل.
مكافحة التعرج (Anti-aliasing). يختلف عرض المنحنيات والحدود بحسب وحدة معالجة الرسومات (GPU) أو غيابها والتهيئة الرسومية. عادةً ما تعمل runners CI بدون تسريع رسومي، مما يغير التنعيم.
الرسوم المتحركة والانتقالات. يمكن التقاط مكون يحتوي على رسوم CSS متحركة في حالة وسيطة إذا لم يتم التحكم في التوقيت بشكل مثالي. على جهازك السريع، تنتهي الرسوم المتحركة. على runner CI محمّل، لا تزال جارية.
منفذ العرض والتحجيم. تستخدم runners GitHub Actions دقة افتراضية قد تختلف عن تهيئتك المحلية. DPI مختلف يغير العرض.
هذه الاختلافات طفيفة — غالباً بضع بكسلات فقط — لكنها كافية لتوليد سيل من الإيجابيات الكاذبة التي تجعل pipeline الخاص بك غير صالح للاستخدام.
المقاربات المتاحة
المقاربة 1: Playwright + toHaveScreenshot() في سير عمل GitHub Actions
يُعد Playwright حالياً الأداة مفتوحة المصدر الأفضل تجهيزاً للاختبار البصري في CI. تتولى طريقته toHaveScreenshot() الالتقاط والمقارنة وتخزين الصور المرجعية.
المبدأ. تكتب اختبارات Playwright تنتقل إلى صفحاتك، وتنتظر استقرار المحتوى، وتلتقط لقطة شاشة تُقارن بصورة مرجعية مخزنة في مستودعك. يقوم سير عمل GitHub Actions بتثبيت Playwright ومتصفحاته، وتنفيذ الاختبارات، والإبلاغ عن النتائج.
لتهيئة سير عمل YAML، يمكن لمساعدك الذكي المفضل أن يُنشئ لك قالباً جاهزاً للاستخدام — فهو حرفياً يعيش من أجل ذلك، هذا كل ما لديه. على محمل الجد، الوثائق الرسمية لـ Playwright لـ GitHub Actions ممتازة ويتم تحديثها باستمرار.
المميزات. كل شيء مفتوح المصدر ومجاني. الصور المرجعية في مستودعك. لا خدمة خارجية. يدير Playwright أصلياً انتظار الاستقرار البصري مع إعادة المحاولة التلقائية.
القيود العملية. يجب أن يتم الإنشاء الأول للصور المرجعية في بيئة CI، وليس محلياً. هذه هي القاعدة الذهبية التي يكتشفها الكثيرون بعد ساعات من تصحيح الإيجابيات الكاذبة. الصور المرجعية المُنشأة على جهاز Mac لن تتطابق مع عرض runner Ubuntu.
التحدي الآخر هو صيانة الصور المرجعية. كل تغيير بصري مقصود — إعادة تصميم، تغيير لون، خط جديد — يتطلب تحديث الصور المرجعية. مع --update-snapshots، الأمر بسيط لاختبار واحد. مع 200 صفحة، يصبح عملية بحد ذاتها.
المقاربة 2: الخدمات السحابية (Percy، Chromatic، Applitools)
تقدم خدمات الاختبار البصري السحابية إجراءات رسمية لـ GitHub Actions. المبدأ: يلتقط سير عمل CI اللقطات ويرسلها إلى الخدمة السحابية، التي تتولى المقارنة والعرض متعدد المتصفحات ولوحة المراجعة.
المبدأ. تضيف الإجراء الرسمي للخدمة إلى سير عملك، وتهيئ رمز API، وكل push يطلق التقاطاً بصرياً. تظهر النتيجة كـ check على pull request الخاص بك.
المميزات. تُسند مشكلة العرض غير الحتمي إلى طرف خارجي — الخدمة السحابية تعرض الصفحات في بيئة محكمة ومستقرة. لوحة المراجعة احترافية. الاختبار عبر المتصفحات يعمل بدون تهيئة.
القيود. التكلفة. تفرض جميع هذه الخدمات رسوماً بحسب حجم اللقطات، والأسعار ترتفع بسرعة مع نمو تطبيقك. الاعتماد على خدمة خارجية يعني أيضاً أن أي عطل من جانبهم يحجب merge requests الخاصة بك — إذا هيأت الـ check كإلزامي. ولقطات شاشتك تمر عبر بنية تحتية لطرف ثالث، مما قد يثير تساؤلات حول الامتثال.
المقاربة 3: BackstopJS في GitHub Actions
BackstopJS هي أداة مفتوحة المصدر للانحدار البصري يمكن تهيئتها عبر سيناريوهات JSON. تعمل في GitHub Actions عبر حاوية Docker أو تثبيت مباشر.
المبدأ. تحدد سيناريوهاتك (عناوين URL، أحجام العرض، المحددات للالتقاط)، يلتقط BackstopJS لقطات الشاشة ويقارنها بالصور المرجعية. يُنشأ تقرير HTML كقطعة أثرية لسير العمل.
المميزات. مفتوح المصدر، مجاني، وتقرير HTML أكثر قابلية للقراءة من مقارنة صور خام.
القيود. تصبح التهيئة عبر سيناريوهات JSON مطولة للتطبيقات المعقدة. شهد المشروع فترات صيانة متفاوتة. وكما هو الحال مع Playwright، تبقى مشكلة الصور المرجعية المُنشأة في بيئات مختلفة قائمة.
المقاربة 4: Delta-QA — الاختبار البصري الذي يبسط CI
يقدم Delta-QA مقاربة مختلفة للاختبار البصري في GitHub Actions. بدلاً من مطالبتك بكتابة سكربتات اختبار وإدارة الصور المرجعية في Git وتصحيح الإيجابيات الكاذبة المرتبطة بالبيئة، يتولى Delta-QA الالتقاط والمقارنة بشكل مستقل.
ما الذي يتغير عملياً. يُطلق سير عمل GitHub Actions الخاص بك Delta-QA، الذي يتولى التقاط صفحاتك في بيئة عرض مستقرة ومحكمة. تُدار الصور المرجعية بواسطة الأداة، وليس بمستودع Git الخاص بك. تختفي الإيجابيات الكاذبة المرتبطة باختلافات البيئة لأن العرض يتم دائماً في نفس السياق.
واجهة المراجعة. عند اكتشاف فرق، يظهر في واجهة مخصصة — ليس في مجلد ملفات PNG ولا في سجل CI من 500 سطر. يمكن لفريق QA والمصممين مراجعة التغييرات البصرية بدون الحاجة إلى الوصول إلى GitHub.
لا سكربتات للصيانة. الاختبار البصري غير مرتبط بحزمة اختباراتك. ليست لديك اختبارات Playwright أو سيناريوهات JSON لتحديثها عند تطور تطبيقك.
المزالق الشائعة للاختبار البصري في CI
بغض النظر عن المقاربة المختارة، هذه المزالق تتربص بأي فريق يخوض الاختبار البصري في CI.
المزلق 1: إنشاء الصور المرجعية محلياً
هذا هو الخطأ الأكثر شيوعاً. تُنشئ صورك المرجعية على جهازك، وتعمل لها commit، وفي CI، تفشل جميع الاختبارات. الحل: أنشئ الصور المرجعية دائماً في بيئة CI، أو استخدم أداة تدير هذا الاستقرار نيابة عنك.
المزلق 2: اختبار صفحات كثيرة في وقت مبكر جداً
الحماس الأولي يدفع لالتقاط جميع صفحات التطبيق. النتيجة: pipeline بطيء، مئات الفروقات للمراجعة مع كل تغيير CSS شامل، وفريق ينتهي بتجاهل النتائج. ابدأ بالصفحات الحرجة — الصفحة الرئيسية، صفحة الدفع، لوحة التحكم — ووسّع تدريجياً.
المزلق 3: جعل الفحص حاجباً فوراً
إذا كان الاختبار البصري يحجب دمج pull requests من اليوم الأول، سيكره مطوروك الأمر بسرعة. ابدأ في الوضع الإعلامي: الفحص يبلغ عن الفروقات بدون حجب. عندما تترسخ الثقة في الأداة وتُسيطر على الإيجابيات الكاذبة، انتقل إلى الوضع الحاجب.
المزلق 4: تجاهل المحتوى الديناميكي
التواريخ، بيانات المستخدمين، المحتوى المحمّل عبر API — كل ما يتغير بين تنفيذين يجب أن يُحاكى أو يُخفى. وإلا، ينتج كل تنفيذ فروقات ليست انحدارات. يمكن للذكاء الاصطناعي التوليدي كتابة المحاكيات نيابة عنك، لكنه قد يهلوس بيانات أكثر إبداعاً من مستخدميك الحقيقيين.
المزلق 5: غياب سير عمل مراجعة واضح
الاختبار البصري الفاشل ليس كالاختبار الوحدوي الفاشل. الفرق قد يكون مقصوداً (إعادة تصميم) أو عرضياً (انحدار). بدون سير عمل واضح لفرز التغييرات والموافقة عليها أو رفضها، يتحول الاختبار البصري إلى ضوضاء.
تحسين وقت التنفيذ
الاختبار البصري أبطأ بطبيعته من الاختبارات الوحدوية — يجب فتح متصفح، وتحميل صفحات، وانتظار الاستقرار، والتقاط لقطات شاشة. في GitHub Actions، كل دقيقة تُحسب (حرفياً، إذا كنت تدفع مقابل الـ runners).
وزّع بالتوازي. يدعم GitHub Actions مصفوفات الاستراتيجية. وزّع اختباراتك البصرية على عدة jobs متوازية لتقسيم الوقت الإجمالي.
استهدف التغييرات. لا حاجة لاختبار التطبيق بأكمله بصرياً إذا كان commit يمس مكوناً محدداً فقط. تتيح بعض الأدوات استهداف الاختبارات بناءً على الملفات المعدّلة.
خزّن المتصفحات مؤقتاً. يستغرق تثبيت Chromium عبر Playwright وقتاً. استخدم التخزين المؤقت في GitHub Actions لتجنب تنزيله في كل تنفيذ.
استخدم runners أقوى. runners GitHub Actions القياسية مناسبة للاختبارات الوحدوية لكنها متواضعة لعرض الصفحات المعقدة. runners الكبيرة أو self-hosted runners تقلل بشكل ملحوظ من وقت الالتقاط.
الأسئلة الشائعة
هل يبطئ الاختبار البصري في GitHub Actions الـ pipeline كثيراً؟
يعتمد ذلك على عدد الصفحات المختبرة والمقاربة المختارة. اختبار بصري لـ 10 صفحات مع Playwright يضيف عادةً من 2 إلى 5 دقائق. مع 100 صفحة، توقع 15 إلى 30 دقيقة بدون توزيع متوازٍ. تُسند الخدمات السحابية العرض خارجياً، مما يقلل الحمل على runners لكن يضيف تأخر الشبكة. يُحسّن Delta-QA هذه العملية لتقليل التأثير على pipeline الخاص بك.
هل runners self-hosted ضرورية للاختبار البصري؟
لا، لكنها تساعد. runners المُستضافة من GitHub تعمل للاختبار البصري، لكن تهيئة عتادها المتغيرة قد تُدخل تباينات في العرض. توفر runners self-hosted بيئة أكثر استقراراً وعادةً أسرع. إنه استثمار يُبرر إذا كان الاختبار البصري محورياً في pipeline الخاص بك.
كيف تُدار الصور المرجعية عندما يعمل عدة مطورين بالتوازي؟
هذه من أكثر المشاكل التي يُستهان بها. مع صور مرجعية مخزنة في Git، تكون تعارضات الدمج في الملفات الثنائية (PNG) متكررة ومؤلمة الحل. تدير الخدمات السحابية الصور المرجعية لكل فرع تلقائياً. يتجنب Delta-QA هذه المشكلة بإدارة الصور المرجعية بشكل مستقل عن مستودع Git الخاص بك.
هل يمكن استخدام الاختبار البصري في GitHub Actions مع تطبيقات تتطلب مصادقة؟
نعم، لكنه يتطلب تهيئة محددة. يجب أتمتة تسجيل الدخول قبل التقاط لقطات الشاشة — إما عبر ملفات تعريف ارتباط مُهيأة مسبقاً أو سكربت مصادقة. يجب تخزين أسرار GitHub (الرموز، كلمات المرور) في GitHub Secrets، وليس أبداً بنص صريح في سير العمل. تدعم جميع أدوات الاختبار البصري هذا السيناريو بدرجات متفاوتة من السهولة.
هل يحل الاختبار البصري في CI محل المراجعة البصرية البشرية؟
لا. يكتشف الاختبار البصري الآلي التغييرات — لا يحكم إن كانت جيدة أو سيئة. ينبهك أن عنصراً قد تغير. بعدها يقرر الإنسان (مطور، مصمم، QA) ما إذا كان التغيير مقصوداً أم أنه انحدار. أفضل العمليات تجمع بين الاكتشاف الآلي وعملية مراجعة بشرية منظمة.
ما الفرق بين اختبار بصري واختبار لقطة شاشة تقليدي؟
اختبار لقطة الشاشة التقليدي يلتقط صورة ويخزنها — هو لقطة وليس تحققاً. يذهب الاختبار البصري أبعد: يقارن تلقائياً لقطة الشاشة الحالية بصورة مرجعية معتمدة، ويحدد مناطق الاختلاف، ويبلغ عن التباينات. المقارنة هي التي تمنح القيمة، وليس الالتقاط.
الخلاصة
GitHub Actions منصة CI/CD ممتازة. الاختبار البصري ممكن تماماً فيها. لكن لا تقلل من التعقيد الخاص بالاختبار البصري في بيئة CI: العرض غير الحتمي، إدارة الصور المرجعية، الإيجابيات الكاذبة، وسير عمل المراجعة هي تحديات يعالجها كل نهج بشكل مختلف.
إذا أردت التحكم في كل جانب من العملية وكان فريقك يملك الكفاءات لصيانة البنية التحتية، فإن Playwright في GitHub Actions خيار متين. إذا فضلت إسناد التعقيد خارجياً، فالخدمات السحابية تعمل لكن بتكلفة متصاعدة.
وإذا كنت تبحث عن مقاربة تبسط جذرياً الاختبار البصري في CI دون التضحية بالتحكم أو تضخيم الميزانية، فقد صُمم Delta-QA تحديداً لهذا السيناريو.