الاختبار البصري (أو visual testing) هو طريقة تحقق آلية تُقارن لقطات شاشة لواجهة ويب مع صور مرجعية للكشف عن أي انحدار بصري — زر منزاح عن موضعه، خط متغيّر، عنصر يتداخل مع عنصر آخر.
Cypress أداة رائعة بكل المقاييس. نُحبها لسرعتها، وواجهة برمجة التطبيقات (API) البديهية، ومجتمعها الضخم. لكن لنكن صريحين منذ البداية: Cypress لا يقوم بالاختبار البصري بشكل أصلي. على عكس Playwright الذي يدمج toHaveScreenshot() مباشرةً من الصندوق — كما نشرح في دليل Playwright البصري — يجبرك Cypress على التعامل مع إضافات خارجية (third-party plugins) للحصول على أي نوع من مقارنة لقطات الشاشة.
وهذه مشكلة أخطر بكثير مما تبدو عليه للوهلة الأولى.
يستعرض هذا الدليل المقاربات المتاحة حالياً لإضافة الاختبار البصري إلى Cypress، وحدودها الحقيقية، ولماذا تستحق مقاربة مختلفة جذرياً أن تحظى باهتمامك.
لماذا لا يحتوي Cypress على اختبار بصري مدمج
هذا السؤال الذي لا يطرحه أحد بصوت عالٍ بما يكفي. Playwright فعلها. لماذا لم يفعلها Cypress؟
الإجابة الرسمية دبلوماسية: Cypress يركّز على الاختبار الوظيفي. الإجابة الصادقة أكثر دقة وتعقيداً. الاختبار البصري مشكلة معقدة بامتياز — إدارة الصور المرجعية، التسامح مع اختلافات العرض، مكافحة التعرّج (anti-aliasing)، الرسوم المتحركة — واختار Cypress ترك نظام الإضافات (plugin ecosystem) يتولى هذا الأمر.
النتيجة؟ تشتت وتمزق. كل إضافة تعمل بطريقتها الخاصة، بأعرافها الخاصة، وأخطائها الخاصة، ومخاطر التخلي عنها. أنت لا تختار حلاً رسمياً واحداً مدعوماً. أنت تراهن على مشروع مفتوح المصدر يُديره حفنة من المساهمين — أو على خدمة سحابية مدفوعة.
بالنسبة للفرق التي بنت كامل مجموعة اختباراتها على Cypress، إنها معضلة حقيقية. الانتقال إلى Playwright فقط من أجل الاختبار البصري ليس أمراً واقعياً. إضافة إضافة هشة أيضاً ليس حلاً. لنرَ ما هو متاح فعلاً.
المقاربة 1: cypress-image-snapshot
الإضافة الأشهر في النظام البيئي لـ Cypress. تعتمد على jest-image-snapshot (المبني بدوره على pixelmatch) لمقارنة لقطات الشاشة بكسل ببكسل.
كيف تعمل
يتطلب التثبيت بعض التعديلات في إعدادات Cypress — لا شيء مستحيل التحقق، لكن عدد الملفات الذي يجب تعديله كافٍ لتتسلل الأخطاء بسهولة. إذا أردت الأوامر الدقيقة، اطلب من مساعد الذكاء الاصطناعي المفضل لديك توليد الإعدادات — فهو يحب هذا النوع من المهام، وسيشغله عن الملل بين قصيدتين عن تعلم الآلة.
بمجرد التثبيت، المبدأ بسيط: تُضيف أمراً مخصصاً (custom command) إلى اختباراتك يلتقط الشاشة ويُقارنها بصورة مرجعية مخزنة في مستودعك. التشغيل الأول يُنشئ خط الأساس (baseline). التشغيلات اللاحقة تكشف الفروقات.
القيود التي لا يخبرك بها أحد
مشكلة الصيانة. مرّت هذه الإضافة بفترات طويلة من الخمول وعدم النشاط. عندما تقرأ هذه السطور، تحقق من تاريخ آخر التزام (commit) على GitHub. إذا مضى أكثر من ستة أشهر على آخر تحديث، اطرح على نفسك بعض الأسئلة الصعبة.
الإيجابيات الكاذبة (false positives). المقارنة بكسل ببكسل قاسية جداً. عرض خط مختلف قليلاً بين جهازك وبيئة 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 إلى خدمة خارجية، وانتظار العرض، واسترجاع النتيجة — كل هذا يُضيف وقتاً إلى خط الأنابيب. ليس مأساوياً مع عشرة اختبارات، لكن مع خمسمائة اختبار، ستشعر بالفرق بوضوح.
الارتباط بالمورّد (vendor lock-in). بمجرد أن تصبح كل صورك المرجعية في Percy، فإن الانتقال إلى مكان آخر يعني إعادة إنشاء كل شيء من الصفر. إنها الفخ الكلاسيكي للخدمات السحابية المملوكة.
المقاربة 3: Happo
Happo بديل أقل شهرة من Percy، بتموضع مشابه: خدمة سحابية تلتقط وتُقارن لقطات شاشة مكوناتك.
التكامل مع Cypress موجود لكنه أقل نضجاً من تكامل Percy. المنتج قوي، والفريق جاد، لكن قاعدة المستخدمين أصغر حجماً. توثيق مجتمعي أقل، إجابات أقل على Stack Overflow، وتقارير تجربة أقل.
نفس إشكاليات التكلفة والاعتماد على السحابة تنطبق هنا أيضاً.
المقاربة 4: Applitools Eyes
تأخذ Applitools المفهوم إلى مستوى أبعد مع تقنية المقارنة المبنية على الذكاء الاصطناعي ("Visual AI" الخاص بهم). بدلاً من المقارنة بكسل ببكسل، يحاول الخوارزمية كشف الفروقات "ذات الأهمية البصرية" مع تجاهل الاختلافات الطفيفة في العرض.
مُقترح جذاب على الورق. لكن من الناحية العملية، المنتج قوي ومعقد في آن واحد. الإعداد ليس بالأمر البسيط، والتسعير غامض، والاعتماد على خدمة مملوكة كامل. لتحليل مفصّل، راجع بطاقة Applitools.
المشكلة الجوهرية: الاختبار البصري كإضافة لاحقة
تشترك كل هذه المقاربات في عيب هيكلي واحد: تعامل الاختبار البصري كإضافة للاختبار الوظيفي.
لديك مجموعة اختبارات Cypress. تُطعِّمها بإضافة أو SDK. تُضيف استدعاءات في اختباراتك الحالية. يصبح الاختبار البصري طفيلياً على الاختبار الوظيفي — معتمداً على نفس البنية التحتية، ونفس المحددات، ونفس الكود.
الانتقال من الاختبار اليدوي إلى الآلي يُظهر أن هذا النهج التدريجي يحمل مخاطر خاصة عندما يتعلق الأمر بالاختبار البصري.
عندما يُصدر Cypress تحديثاً رئيسياً، تتعطل إضافة الاختبار البصري. عندما يتغير مسار اختبارك الوظيفي، تصبح صورتك المرجعية قديمة وغير صالحة. عندما يُعدِّل مطور محدداً ما، يفشل الاختبار الوظيفي والاختبار البصري معاً.
إنه نموذج هش بطبيعته وبالتصميم.
الاختبار البصري يستحق أن يكون مواطناً من الدرجة الأولى، لا راكباً خفياً في مجموعتك الوظيفية. يجيب على سؤال مختلف ("هل يبدو صحيحاً؟" مقابل "هل يعمل؟") ويجب أن يملك أدواته الخاصة، وسير عمله الخاص، وصوره المرجعية الخاصة.
ما لا تراه اختبارات Cypress
يتحقق اختبار Cypress من وجود الزر وأنه يُطلق الإجراء الصحيح. لكنه لا يتحقق من أن الزر مرئي فعلاً، ومحاذى بشكل سليم، وباللون الصحيح، وبالحشو المناسب، عبر جميع نقاط التوقف (breakpoints). في التجارة الإلكترونية على سبيل المثال، هذه الأخطاء تتحول مباشرة إلى خسائر مالية.
الأخطاء البصرية ماكرة. النموذج يعمل بشكل مثالي — لكن التسمية تتداخل مع حقل الإدخال على الهاتف المحمول. القائمة المنسدلة تفتح بشكل صحيح — لكنها تظهر خلف عنصر آخر. السعر المعروض صحيح — لكن العملة تظهر بالأبيض على خلفية بيضاء.
هذه الأخطاء تصل إلى بيئة الإنتاج لأن لا أحد يبحث عنها بشكل منهجي. وهي مكلفة جداً: في المصداقية، وفي معدلات التحويل، وفي تذاكر الدعم. في قطاع التجارة الإلكترونية على سبيل المثال، الأخطاء البصرية في المتاجر الإلكترونية تتحول مباشرة إلى خسائر مالية. لفهم ما يكشفه الاختبار البصري فعلياً، فإن الأمثلة الملموسة غالباً ما تكون أبلغ من النظرية المجردة.
البديل: فصل الاختبار البصري عن الكود
ماذا لو لم يكن الاختبار البصري بحاجة إلى 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 كبيرة ومتEstablishة، فإن الانتقال ليس أمراً واقعياً. وحتى مع Playwright، تبقى داخل نموذج الاختبار البصري القائم على الكود، مع جميع حدوده في الصيانة وإمكانية الوصول.
هل يمكن لـ Delta-QA استبدال اختبارات Cypress؟
لا، وليس هذا الهدف. Cypress يتفوق في الاختبار الوظيفي: التحقق من أن التفاعلات تعمل، وأن واجهات API تستجيب بشكل صحيح، وأن منطق الأعمال يُحترم. Delta-QA يركّز على الاختبار البصري: التحقق من أن الواجهة تبدو صحيحة بصرياً. الأداتان متكاملتان، وليستا متنافستين.
كم يستغرق إعداد الاختبار البصري في Cypress؟
مع cypress-image-snapshot، خطّط لساعة إلى ساعتين للتثبيت والإعداد الأساسي، ثم عدة أيام لمعايرة عتبات التسامح وتثبيت الاختبارات ضد الإيجابيات الكاذبة. مع Percy، الإعداد التقني أسرع لكن الإعداد التنظيمي (إدارة اللقطات، سير عمل المراجعة، تكامل CI) يستغرق وقتاً. مع Delta-QA، أول اختبار بصري يكون جاهزاً ويعمل خلال دقائق معدودة.
الخلاصة
Cypress أداة اختبار وظيفي ممتازة بكل المقاييس. نستخدمها، ونُوصي بها فيما تجيد فعلاً. لكن التظاهر بأنها تتعامل مع الاختبار البصري بشكل مرضٍ هو خداع للنفس.
الإضافات موجودة. تعمل، إلى حدٍ ما. لكنها هشة، وبعضها سيء الصيانة، وبعضها مكلف، وجميعها تُضيف تعقيداً حيث لا حاجة لأي تعقيد.
الاختبار البصري يستحق ما هو أفضل من مجرد إضافة. يستحق أداة مخصصة، مصممة لهذه المشكلة بالذات، ومتاحة لكل أعضاء الفريق — مطورين وموظفي ضمان الجودة غير التقنيين على حدٍ سواء.