Cypress Visual Testing: الدليل الشامل لإضافة الاختبار البصري
الاختبار البصري (أو visual testing) هو طريقة تحقق آلية تقارن لقطات شاشة لواجهة ويب مع صور مرجعية للكشف عن أي انحدار رسومي — زر منزاح، خط متغيّر، عنصر يتداخل مع آخر.
Cypress أداة رائعة. نحبها لسرعتها، وواجهة API البديهية، ومجتمعها الضخم. لكن لنكن صريحين منذ البداية: Cypress لا يقوم بالاختبار البصري بشكل أصلي. على عكس Playwright الذي يدمج toHaveScreenshot() مباشرةً، يجبرك Cypress على التعامل مع إضافات خارجية للحصول على أدنى مقارنة للقطات الشاشة.
وهذه مشكلة أخطر مما تبدو.
يستعرض هذا الدليل المقاربات الحالية لإضافة الاختبار البصري إلى Cypress، وحدودها الحقيقية، ولماذا تستحق مقاربة مختلفة جذرياً اهتمامك.
لماذا لا يحتوي Cypress على اختبار بصري مدمج
هذا السؤال الذي لا يطرحه أحد بصوت عالٍ كفاية. Playwright فعلها. لماذا لم يفعل Cypress؟
الإجابة الرسمية دبلوماسية: Cypress يركز على الاختبار الوظيفي. الإجابة الصادقة أكثر دقة. الاختبار البصري مشكلة معقدة — إدارة الصور المرجعية، التسامح مع اختلافات العرض، مكافحة التعرج، الرسوم المتحركة — واختار Cypress ترك نظام الإضافات يتولى الأمر.
النتيجة؟ تشتت. كل إضافة تفعل الأمور بطريقتها، بأعرافها الخاصة، وأخطائها الخاصة، ومخاطر التخلي عنها. أنت لا تختار حلاً رسمياً واحداً مدعوماً. أنت تراهن على مشروع مفتوح المصدر يديره حفنة من المساهمين — أو على خدمة سحابية مدفوعة.
بالنسبة للفرق التي بنت كامل مجموعة اختباراتها على Cypress، إنها معضلة حقيقية. الانتقال إلى Playwright فقط من أجل الاختبار البصري ليس واقعياً. إضافة مكوّن هش أيضاً ليس حلاً. لنرَ ما هو متاح.
المقاربة 1: cypress-image-snapshot
الإضافة الأشهر في النظام البيئي. تعتمد على jest-image-snapshot (المبني بدوره على pixelmatch) لمقارنة لقطات الشاشة بكسل ببكسل.
كيف تعمل
يتطلب التثبيت بعض التعديلات في إعدادات Cypress — لا شيء مستحيل، لكن ملفات كافية للتعديل بحيث يمكن أن يتسلل خطأ بسهولة. إذا أردت الأوامر الدقيقة، اطلب من مساعد الذكاء الاصطناعي المفضل لديك توليد الإعدادات: يحب ذلك، وسيمنعه من الملل بين قصيدتين عن تعلم الآلة.
بمجرد التثبيت، المبدأ بسيط: تضيف أمراً مخصصاً لاختباراتك يلتقط الشاشة ويقارنها بصورة مرجعية مخزنة في مستودعك. التشغيل الأول ينشئ خط الأساس. التشغيلات اللاحقة تكشف الفروقات.
القيود التي لا يخبرك بها أحد
مشكلة الصيانة. مرّت هذه الإضافة بفترات طويلة من الخمول. عندما تقرأ هذه السطور، تحقق من تاريخ آخر commit على GitHub. إذا مضى أكثر من ستة أشهر، اطرح على نفسك بعض الأسئلة.
الإيجابيات الكاذبة. المقارنة بكسل ببكسل قاسية. عرض خط مختلف قليلاً بين جهازك وبيئة CI؟ إيجابية كاذبة. مكافحة تعرج يختلف حسب بطاقة الرسوميات؟ إيجابية كاذبة. تقضي وقتاً أكثر في معايرة عتبات التسامح مما تقضيه في كتابة الاختبارات.
لا واجهة مراجعة. عندما يفشل اختبار، تحصل على صورة فرق في مجلد. لا لوحة تحكم، لا سير عمل للموافقة. تفتح الصورة في مستعرض الملفات وتحدّق لتجد الفرق. إنه أسلوب حرفي.
إدارة الصور المرجعية في Git. مئات صور PNG في مستودعك. تعارضات الدمج على ملفات ثنائية كابوس. تاريخ Git يتضخم. بعض الفرق ينتهي بها الأمر باستخدام Git LFS، مما يضيف طبقة إضافية من التعقيد.
المقاربة 2: Percy (BrowserStack)
Percy هو خدمة سحابية للاختبار البصري تتكامل مع Cypress عبر SDK. المقاربة مختلفة جوهرياً: بدلاً من المقارنة محلياً، يرسل Percy الـ DOM والأصول إلى خوادمه، ويعرض الصفحة في متصفحات حقيقية، ويقارن النتائج في لوحة تحكم ويب.
كيف تعمل
تثبّت SDK الخاص بـ Percy لـ Cypress، تضيف استدعاءً في اختباراتك لالتقاط snapshot، وPercy يتولى الباقي في السحابة. سير عمل المراجعة يتم في واجهة Percy الويب: ترى الفروقات، توافق أو ترفض.
للإعدادات الدقيقة، ذكاؤك الاصطناعي المكتبي يمكنه إخراج المقتطف في ثلاث ثوانٍ — إنها لحظة تألقه، دعه يتألق بدلاً من النسخ من توثيق سيصبح قديماً خلال ستة أشهر.
القيود
التكلفة. Percy خدمة مدفوعة. الخطة المجانية موجودة لكنها محدودة بعدد اللقطات شهرياً. لفريق يختبر بجدية، التكاليف ترتفع بسرعة. لن نفصّل الأسعار هنا — تتغير بانتظام — لكن توقع بنداً مالياً غير بسيط.
الاعتماد على السحابة. لقطاتك تُعرض على خوادم Percy. إذا تعطلت الخدمة، اختباراتك تفشل. إذا قرر BrowserStack (الذي استحوذ على Percy) تغيير الأسعار أو الشروط، ليس لديك أي نفوذ.
زمن الاستجابة في CI. إرسال الـ DOM لخدمة خارجية، انتظار العرض، استرجاع النتيجة — يضيف وقتاً لخط الأنابيب. ليس مأساوياً مع عشرة اختبارات، لكن مع خمسمائة، ستشعر به.
الارتباط بالمورّد. بمجرد أن تكون كل صورك المرجعية في Percy، الانتقال لمكان آخر يعني إعادة إنشاء كل شيء من الصفر. إنها الفخ الكلاسيكي للخدمات السحابية المملوكة.
المقاربة 3: Happo
Happo بديل أقل شهرة لـ Percy، بتموضع مشابه: خدمة سحابية تلتقط وتقارن لقطات شاشة مكوناتك.
التكامل مع Cypress موجود لكنه أقل نضجاً من Percy. المنتج قوي، الفريق جاد، لكن قاعدة المستخدمين أصغر. توثيق مجتمعي أقل، إجابات أقل على Stack Overflow، تجارب مشاركة أقل.
نفس إشكاليات التكلفة والاعتماد على السحابة تنطبق.
المقاربة 4: Applitools Eyes
Applitools يأخذ المفهوم أبعد مع تقنية المقارنة المبنية على الذكاء الاصطناعي ("Visual AI" الخاص بهم). بدلاً من مقارنة بكسل ببكسل، يحاول الخوارزمية كشف الفروقات "المهمة بصرياً" متجاهلاً الاختلافات الطفيفة في العرض.
جذاب على الورق. عملياً، المنتج قوي لكنه معقد. الإعداد ليس بسيطاً، التسعير غامض، والاعتماد على خدمة مملوكة كامل. لتحليل مفصّل، راجع بطاقة Applitools.
المشكلة الجوهرية: الاختبار البصري كإضافة
كل هذه المقاربات تشترك في عيب هيكلي: تعامل الاختبار البصري كإضافة للاختبار الوظيفي.
لديك مجموعة اختبارات Cypress. تطعّمها بإضافة أو SDK. تضيف استدعاءات في اختباراتك الحالية. يصبح الاختبار البصري طفيلياً على الاختبار الوظيفي — معتمداً على نفس البنية التحتية، نفس المحددات، نفس الكود.
عندما يصدر Cypress تحديثاً رئيسياً، إضافة الاختبار البصري تتعطل. عندما يتغير مسار اختبارك الوظيفي، صورتك المرجعية تصبح قديمة. عندما يعدّل مطور محدداً، يفشل الاختبار الوظيفي والبصري معاً.
إنه نموذج هش بطبيعته.
الاختبار البصري يستحق أن يكون مواطناً من الدرجة الأولى، لا راكباً خفياً في المجموعة الوظيفية. يجيب على سؤال مختلف ("هل يبدو صحيحاً؟" مقابل "هل يعمل؟") ويجب أن يملك أدواته الخاصة، وسير عمله الخاص، وصوره المرجعية الخاصة.
ما لا تراه اختبارات Cypress
اختبار Cypress يتحقق من وجود الزر وأنه يطلق الإجراء الصحيح. لا يتحقق من أن الزر مرئي، ومحاذى بشكل صحيح، وباللون الصحيح، وبالحشو المناسب، على جميع نقاط التوقف.
الأخطاء البصرية ماكرة لأنها تجتاز كل الاختبارات الوظيفية. النموذج يعمل بشكل مثالي — لكن التسمية تتداخل مع حقل الإدخال على الهاتف. القائمة المنسدلة تفتح بشكل صحيح — لكنها تظهر خلف عنصر آخر. السعر المعروض صحيح — لكن العملة تظهر بالأبيض على خلفية بيضاء.
هذه الأخطاء تصل للإنتاج لأن لا أحد يبحث عنها بشكل منهجي. وهي مكلفة: في المصداقية، في التحويلات، في تذاكر الدعم. لفهم ما يكشفه الاختبار البصري فعلياً، الأمثلة الملموسة غالباً أبلغ من النظرية.
البديل: فصل الاختبار البصري عن الكود
ماذا لو لم يكن الاختبار البصري بحاجة لـ Cypress أصلاً؟
هذا الموقف الذي ندافع عنه في Delta-QA، ونتبناه بالكامل. الاختبار البصري لا يحتاج كوداً. لا يحتاج إضافات. لا يحتاج محددات CSS ولا إعدادات webpack.
Delta-QA يعمل بشكل مختلف. تتصفح موقعك، تسجل مساراً بالنقر والتوجيه، والأداة تلتقط لقطات الشاشة المرجعية. في كل تشغيل لاحق، تقارن وتعرض لك الفروقات في واجهة مخصصة. بدون كود. بدون إضافات. بدون اعتماد على Cypress أو Playwright أو أي شيء آخر.
ليس حلاً وسطاً. إنها فلسفة مختلفة. الاختبار الوظيفي والاختبار البصري تخصصان مختلفان يستحق كل منهما أدواته الخاصة. مجموعة اختبارات Cypress تواصل التحقق من أن كل شيء يعمل. Delta-QA يتحقق من أن كل شيء يبدو صحيحاً. يكملان بعضهما دون تعارض.
لفرق QA التي لا تبرمج، إنه تحرير. للمطورين، إنه توفير للوقت. للجميع، إنه إيجابيات كاذبة أقل وسير عمل مراجعة منطقي. اكتشف لماذا الاختبار البصري بدون كود يغيّر قواعد اللعبة.
الأسئلة الشائعة
هل يمكن لـ Cypress إجراء اختبار بصري بدون إضافة؟
لا. يمكن لـ Cypress التقاط لقطات شاشة باستخدام cy.screenshot()، لكنه لا يقدم أي آلية مقارنة أصلية. تحصل على صور، لكن المقارنة مع المرجعيات وإدارة عتبات التسامح وسير عمل الموافقة يجب إضافتها عبر إضافة أو خدمة خارجية.
ما أفضل إضافة Cypress للاختبار البصري؟
لا توجد إجابة عالمية. cypress-image-snapshot الأكثر شيوعاً في المصادر المفتوحة لكنها تعاني من مشاكل الصيانة والإيجابيات الكاذبة. Percy يقدم أفضل تجربة مستخدم لكنها خدمة مدفوعة. "الأفضل" يعتمد على ميزانيتك، وتحملك للإيجابيات الكاذبة، واستعدادك لصيانة كود إضافي.
هل Percy مجاني مع Cypress؟
يقدم Percy خطة مجانية بعدد محدود من اللقطات الشهرية. للاستخدام المهني الجاد، ستحتاج خطة مدفوعة. الأسعار تتغير بانتظام، راجع موقعهم للشروط الحالية.
هل يمكن إجراء اختبار بصري Cypress في CI/CD؟
نعم، كل المقاربات المذكورة تعمل في CI/CD. لكن هنا تتضاعف المشاكل: اختلافات العرض بين البيئات، إدارة الصور المرجعية، وقت التنفيذ. الـ CI يضخّم كل هشاشة في إعداد اختبارك البصري.
لماذا لا نستخدم Playwright ببساطة للاختبار البصري؟
إذا كنت تبدأ مشروعاً جديداً، Playwright مع toHaveScreenshot() المدمج هو فعلاً خيار أفضل للاختبار البصري البرمجي. لكن إذا كان لديك مجموعة اختبارات Cypress كبيرة، الانتقال ليس واقعياً. وحتى مع Playwright، تبقى في نموذج الاختبار البصري بالكود، مع حدوده في الصيانة وإمكانية الوصول.
هل يمكن لـ Delta-QA استبدال اختبارات Cypress؟
لا، وليس هذا الهدف. Cypress يتفوق في الاختبار الوظيفي: التحقق من عمل التفاعلات، واستجابة APIs بشكل صحيح، واحترام منطق الأعمال. Delta-QA يركز على الاختبار البصري: التحقق من أن الواجهة تبدو صحيحة. الأداتان متكاملتان، وليستا متنافستين.
كم يستغرق إعداد الاختبار البصري في Cypress؟
مع cypress-image-snapshot، احسب ساعة إلى ساعتين للتثبيت والإعداد الأساسي، ثم عدة أيام لمعايرة عتبات التسامح وتثبيت الاختبارات ضد الإيجابيات الكاذبة. مع Percy، الإعداد التقني أسرع لكن الإعداد التنظيمي (إدارة اللقطات، سير عمل المراجعة، تكامل CI) يأخذ وقتاً. مع Delta-QA، أول اختبار بصري يعمل خلال دقائق.
الخلاصة
Cypress أداة اختبار وظيفي ممتازة. نستخدمه، ونوصي به فيما يجيده. لكن التظاهر بأنه يتعامل مع الاختبار البصري بشكل مرضٍ هو خداع للنفس.
الإضافات موجودة. تعمل، إلى حدٍ ما. لكنها هشة، بعضها سيئ الصيانة، وبعضها مكلف، وجميعها تضيف تعقيداً حيث لا يُحتاج.
الاختبار البصري يستحق أفضل من إضافة. يستحق أداة مخصصة، مصممة لهذه المشكلة بالذات، متاحة لكل الفريق — مطورين وموظفي QA غير التقنيين على حدٍ سواء.