يتمثل اختبار الانحدار البصري في التقاط لقطات شاشة تلقائية لواجهة المستخدم ومقارنتها بصور مرجعية لاكتشاف أي تغيير غير مقصود في المظهر — شبكة أمان لكل ما لا تراه الاختبارات الوظيفية.
النقاش بين Playwright و Cypress هو نقاش كلاسيكي ومستمر في عالم اختبار الواجهات الأمامية. لسنوات، اختلفت الفرق حول الأداء والصياغة البرمجية ودعم المتصفحات المتعددة ومنظومات الإضافات والتكلفة الإجمالية للملكية.
لكن هناك زاوية لا يكاد أحد يتناولها بجدية في هذه المقارنة: الاختبار البصري. وهو بالتحديد المجال الذي تكون فيه الفروقات أكثر كشفاً — وأكثر فائدة لقرارك.
هذه المقارنة لن تخبرك أيهما "الأفضل" بطريقة مطلقة — فالأمر يعتمد على سياق فريقك واحتياجاتك. ستوضح لك ما يفعله كل منهما بشكل جيد وما يفعله بشكل سيئ في اختبارات الانحدار البصري تحديداً. وستنتهي بحقيقة مزعجة للمعسكرين معاً.
Playwright والاختبار البصري: أخيرًا دعم مدمج
ما يقدمه Playwright بشكل مدمج
Playwright هو الوحيد من بين الاثنين الذي يوفر ميزة اختبار بصري مدمجة بالكامل ضمن إطار العمل. الدالة toHaveScreenshot()، المتاحة منذ Playwright 1.22 (مايو 2022)، تسمح بالتقاط صفحة أو عنصر ومقارنته تلقائيًا بصورة مرجعية مخزّنة مسبقاً.
هذه ميزة كبيرة. لا حاجة لتثبيت إضافات، ولا اعتماد على تبعيات خارجية، ولا تهيئة خارجية. الميزة جزء من إطار العمل — موثقة ومختبرة ومحدثة مع كل إصدار.
نقاط قوة Playwright في الاختبار البصري
دعم مدمج لمتصفحات متعددة. يدعم Playwright كلاً من Chromium و Firefox و WebKit (Safari). يمكنك التقاط صفحاتك عبر ثلاثة محركات عرض مختلفة والمقارنة. هذا أمر بالغ الأهمية للاختبار البصري: CSS يعمل بشكل مثالي على Chrome قد ينكسر على Safari.
مقارنة قابلة للتخصيص. يمكنك تحديد عتبة تسامح (نسبة البكسلات المختلفة)، ومقارنة عناصر محددة بدلاً من صفحات كاملة، وإنشاء فروقات بصرية واضحة تُظهر بالضبط ما تغيّر.
تكامل مدمج مع CI/CD. تُخزَّن الصور المرجعية في مستودع Git، وتُنفَّذ المقارنات في خط الأنابيب، وتُعرض النتائج في تقرير HTML الخاص بـ Playwright. لا حاجة لأدوات خارجية.
إدارة الحركات. يمكن لـ Playwright تعطيل حركات CSS تلقائيًا قبل الالتقاط — وهي مصدر رئيسي للإيجابيات الكاذبة في الاختبار البصري. هذه التفصيلة تُظهر أن فريق Microsoft فكّر بعناية في المشكلة.
قيود Playwright في الاختبار البصري
إنه كود. إنشاء اختبار بصري في Playwright يعني كتابة JavaScript أو TypeScript. تهيئة العتبات، إدارة الصور المرجعية، تصحيح الإيجابيات الكاذبة — كل شيء يمر عبر الطرفية ومحرر الكود. إذا كان مسؤول الجودة لديك لا يُبرمج، فـ Playwright ليس خيارًا له.
خوارزمية مقارنة أساسية. خوارزمية المقارنة المدمجة هي مقارنة بكسل ببكسل. فعالة لكنها صارمة: أدنى تغيير في عرض الخطوط (antialiasing، hinting) بين جهازين يمكن أن يُطلق إيجابية كاذبة. كما نوضح في مقالتنا عن مقارنة البكسل مقابل المقارنة الإدراكية، هذا النهج يُحقق دقة عالية لكنه يُكبّدك تكلفة صيانة مرتفعة. للتعامل مع ذلك، تحتاج لتشغيل الاختبارات في بيئة متطابقة تمامًا — عادةً حاوية Docker. وهذا يضيف تعقيدًا.
لا لوحة معلومات للمراجعة. عندما يفشل اختبار بصري، يُنشئ Playwright صورة فرق. لكن لا توجد واجهة لمراجعة الاختلافات، أو الموافقة على التغييرات المقصودة أو رفضها، أو التعاون مع الفريق حول النتائج. إنه سير عمل مطور منفرد، وليس سير عمل فريقي.
المناطق الديناميكية لا تزال مشكلة. التواريخ، الإعلانات، الصور الرمزية، حاويات المحتوى المخصص — كل ما يتغير بين التشغيلات يُولِّد إيجابيات كاذبة. يسمح Playwright بإخفاء العناصر، لكن عليك تحديدها وتهيئتها يدويًا في كل اختبار.
Cypress والاختبار البصري: الغائب الأكبر
ما لا يقدمه Cypress بشكل مدمج
لنكن صريحين: Cypress ليس لديه أي ميزة مدمجة للاختبار البصري. صفر. لا شيء.
لا toHaveScreenshot(). لا مقارنة صور مدمجة على الإطلاق. لا إدارة صور مرجعية. لا شيء في إطار العمل الأساسي يسمح بإجراء اختبارات الانحدار البصري دون الاعتماد على أدوات خارجية.
هذا خيار واعٍ من فريق Cypress، وهو حقهم. لكنه نقص صارخ في 2026، حين تدمج معظم أُطر العمل المنافسة على الأقل إمكانيات أساسية للمقارنة البصرية. لتفاصيل أعمق حول كيفية إضافة الاختبار البصري إلى Cypress، راجع دليل Cypress الشامل للاختبار البصري.
الإضافات: رقعة المجتمع
في غياب ميزة مدمجة، يعتمد Cypress على منظومة إضافاته. تتوفر عدة خيارات:
cypress-image-snapshot: الإضافة التاريخية والأكثر شهرة، المبنية على مكتبة jest-image-snapshot. تعمل بشكل أساسي، لكنها سيئة الصيانة (آخر تحديث مهم يعود إلى 2023) والإيجابيات الكاذبة وفيرة ومُحبِطة. محاولة استخدامها في CI بدون حاوية Docker أشبه بطلب تمييز "الأزرق الداكن" عن "أزرق منتصف الليل" من ذكاء اصطناعي — ممكن تقنيًا، محفوف بالمخاطر عمليًا وغير قابل للاعتماد في الإنتاج.
Percy (BrowserStack): تكامل SaaS سحابي متكامل. يلتقط Cypress لقطات الشاشة ويرسلها إلى خوادم Percy للمقارنة والتخزين. يعمل بشكل جيد فعلاً، لكنه مدفوع بسعر مرتفع (يبدأ من 599 $/شهريًا للفرق)، ولقطاتك تذهب إلى السحابة خارج سيطرتك المباشرة، وأنت تعتمد بالكامل على خدمة طرف ثالث لعملية حرجة. للفرق التي لديها متطلبات سيادة البيانات أو قيود تنظيمية صارمة، هذا أمر مستبعد تماماً.
Applitools Eyes SDK لـ Cypress: نفس منطق SaaS، مع "Visual AI" من Applitools. قوي، لكنه أغلى ومعتمد على السحابة بنفس القدر.
نقاط قوة Cypress (بشكل عام، وليس للاختبار البصري)
لنكن منصفين. لدى Cypress مزايا لا يمكن إنكارها — لكنها ببساطة لا تتعلق بالاختبار البصري.
تجربة المطور ممتازة. التنقل عبر الزمن في التصحيح، إعادة التحميل التلقائي، الواجهة الرسومية — صُمِّم Cypress ليجعل المطورين يستمتعون بكتابة الاختبارات. وهو ينجح في ذلك.
المجتمع ضخم ونشط. ستجد إضافة أو مقالة لكل شيء تقريبًا. الدعم على Stack Overflow سريع.
التوثيق من أفضل ما في السوق. واضح، تدريجي، مع أمثلة عملية.
قيود Cypress (ما وراء الاختبار البصري)
متصفح أساسي واحد. أضاف Cypress دعم متصفحات متعددة، لكن WebKit (Safari) مدعوم فقط في الوضع التجريبي. للاختبار البصري عبر المتصفحات، هذا عائق حقيقي — Safari معروف بأنه المتصفح الذي يكسر أكبر عدد من تخطيطات CSS.
بنية in-process. يعمل Cypress في نفس العملية مع التطبيق المُختبر. هذا ما يتيح التنقل عبر الزمن في التصحيح، لكنه يفرض قيودًا: لا علامات تبويب متعددة، لا دعم أصلي عبر النطاقات، وقيود على iframe.
الأداء على نطاق واسع. في مجموعات اختبار كبيرة، يمكن أن يصبح Cypress أبطأ بشكل ملحوظ من Playwright. التوازي المدمج محدود بدون Cypress Cloud (مدفوع).
المقارنة الحقيقية للاختبار البصري
لنوضح الأمور. إليك ما يهم فعلًا عندما تُقيِّم هاتين الأداتين لاختبارات الانحدار البصري.
ميزة المقارنة البصرية المدمجة
Playwright: نعم، toHaveScreenshot() مدمج. Cypress: لا، يعتمد على إضافات خارجية أو SaaS مدفوع.
هذه النقطة هي الأهم على الإطلاق، وهي ليست لصالح Cypress بأي شكل. عندما تكون الميزة مدمجة، يصونها الفريق الأساسي للمشروع، ويُختبرها مع كل إصدار جديد، ويُوثِّقها رسمياً مع ضمان التوافق. عندما تعتمد على إضافة مجتمعية، ترث مخاطر التخلي عنها وعدم توافق الإصدارات والصيانة غير الكافية والافتقار إلى الدعم الرسمي.
دعم المتصفحات المتعددة
Playwright: Chromium و Firefox و WebKit — جميعها من الدرجة الأولى. Cypress: Chromium و Firefox في الإنتاج، WebKit تجريبي.
للاختبار البصري، الاختبار على WebKit ضروري. حصة كبيرة من مستخدميك على Safari (جوال وسطح مكتب). تجاهل WebKit يعني تجاهل الأخطاء البصرية التي تظهر فقط على Safari — وهي كثيرة.
إدارة الإيجابيات الكاذبة
Playwright: عتبات قابلة للتخصيص، إخفاء العناصر، تعطيل الحركات. لا خوارزمية ذكية، لكن أدوات لتقليل الضوضاء.
Cypress (عبر الإضافات): يعتمد على الإضافة المستخدمة. cypress-image-snapshot يوفر عتبات أساسية. Percy و Applitools يقدمان خوارزميات أكثر تطورًا، لكن في السحابة وبتكلفة عالية. كما نوضح في مقارنة أدوات الاختبار البصري المجانية، توجد بدائل أقل تكلفة.
كلا النهجين يتركان للمطور إدارة المناطق الديناميكية يدويًا. هذا مستهلك للوقت وهش — عنصر ديناميكي جديد في الصفحة، ويفشل اختبارك بدون سبب.
سير عمل المراجعة
Playwright: صور الفروقات في تقرير HTML. لا لوحة معلومات تعاونية. Cypress (عبر Percy/Applitools): لوحة معلومات SaaS كاملة مع موافقة/رفض. لكنها مدفوعة وسحابية.
لا أحد منهما يقدم سير عمل مراجعة متكامل ومحلي ومجاني. هذه فجوة في المنظومة.
إمكانية الوصول لغير المطورين
Playwright: مطورون فقط. Cypress: مطورون فقط.
تعادل. كلتا الأداتين مصممتان بواسطة مطورين ولمطورين. إذا كنت مسؤول جودة بدون خلفية تقنية، أو مصممًا، أو product owner، فلا يمكنك إنشاء اختبارات بصرية بأي منهما دون تعلم البرمجة. هذا التحيز الهيكلي في الصناعة يعني أن معظم الفرق تفتقر إلى التغطية البصرية الكافية رغم أهميتها الواضحة.
الحقيقة المزعجة للمعسكرين
إليك ما لن يخبرك به فريق Playwright ولا فريق Cypress صراحةً: اختبار الانحدار البصري لا ينبغي أن يكون حكرًا على المطورين. هذا تحيز هيكلي في صناعة أدوات الاختبار بأكملها.
فكّر في الأمر لثانية. من يعرف أفضل كيف يجب أن تبدو الواجهة؟ المطور الذي نفَّذ CSS؟ أم المصمم الذي أنشأها ومسؤول الجودة الذي صادق عليها؟
الإجابة واضحة. ومع ذلك، يتطلب إطارا العمل الرئيسيان في السوق مهارات برمجة لإنشاء أبسط اختبار بصري. هذا تحيز منهجي في الصناعة: أُدوات الاختبار بُنيت لمن يكتبون الكود، لا لمن يحكمون على النتيجة.
النتيجة متوقعة ومأساوية في آن: معظم الفرق لا تُجري اختبارات انحدار بصري على الإطلاق. ليس لأنها لا ترى القيمة المضافة — بل لأن المطورين لديهم بالفعل الكثير من المهام الملحّة ولا أحد غيرهم يستطيع القيام بذلك بالأدوات المتاحة حالياً.
لهذا السبب توجد أدوات الاختبار البصري بدون كود. أدوات مثل Delta-QA تسمح لأي شخص بإنشاء اختبارات بصرية بمجرد التصفح في الموقع — بدون كود، بدون طرفية، بدون خط أنابيب لتهيئته. إنه تحول جوهري في إمكانية الوصول للاختبار البصري.
أي أداة تختار؟
اختر Playwright إذا...
كنت فريقًا من المطورين المرتاحين مع TypeScript/JavaScript. تحتاج اختبارات E2E متعددة المتصفحات. تريد اختبارًا بصريًا أساسيًا مدمجًا بدون إضافات خارجية. لديك الموارد للحفاظ على بيئة Docker مستقرة لتجنب الإيجابيات الكاذبة.
اختر Cypress إذا...
كنت فريقًا من المطورين الذين يُقدِّرون تجربة المطور فوق كل شيء. لديك ميزانية لـ Percy أو Applitools. لا تحتاج لاختبار Safari بشكل موثوق. لديك بالفعل استثمار كبير في منظومة Cypress.
اختر أداة بدون كود إذا...
فريق الجودة لديك لا يتكون من مطورين فقط. تريد أن يتمكن المصممون و PO من إنشاء اختبارات بصرية والتحقق منها. تحتاج نتائج بدون إيجابيات كاذبة. تفضل الاحتفاظ ببياناتك محليًا بدلاً من السحابة. تريد البدء بالاختبار البصري اليوم، وليس بعد ثلاثة سبرينتات.
الأسئلة الشائعة
هل Playwright أفضل من Cypress للاختبار البصري في 2026؟
نعم، بشكل موضوعي. يقدم Playwright دالة toHaveScreenshot() المدمجة، ويدعم ثلاثة محركات متصفح، ويدير الحركات تلقائيًا. Cypress ليس لديه شيء مدمج ويعتمد على إضافات خارجية للاختبار البصري. للمطور الذي يريد إجراء اختبارات بصرية، Playwright هو الخيار الأكثر منطقية.
هل يمكن إجراء اختبار بصري مع Cypress بدون إضافة مدفوعة؟
نعم، مع إضافة المصدر المفتوح cypress-image-snapshot. لكن توقع إيجابيات كاذبة متكررة، وصيانة غير مضمونة، وتهيئة مرهقة للحصول على نتائج مستقرة في CI. ممكن، لكنه استثمار وقت كبير.
هل يحتاج الاختبار البصري مع Playwright إلى Docker؟
يُنصح بشدة. خوارزمية المقارنة بكسل ببكسل حساسة لاختلافات العرض بين أنظمة التشغيل (عرض الخطوط، antialiasing). بدون Docker، ستحصل على إيجابيات كاذبة بين جهازك المحلي (macOS/Windows) و CI (Linux). مع Docker، تتحكم في بيئة العرض.
Playwright أم Cypress لفريق QA غير تقني؟
لا هذا ولا ذاك. كلاهما يتطلب مهارات برمجة JavaScript/TypeScript. لفريق QA غير تقني، اتجه إلى أداة بدون كود مثل Delta-QA التي تسمح بإنشاء اختبارات بصرية بمجرد التصفح.
كم من الوقت يستغرق إعداد الاختبار البصري مع Playwright؟
لمطور ذي خبرة: بضع ساعات للاختبارات الأولى، بضعة أيام لمجموعة مستقرة. الاستثمار الحقيقي في إدارة الإيجابيات الكاذبة وصيانة الصور المرجعية — إنه جهد مستمر، وليس مهمة لمرة واحدة.
هل يمكن استخدام Playwright وأداة بدون كود بالتوازي؟
بالتأكيد، بل يُنصح بذلك. استخدم Playwright لاختبارات E2E الوظيفية (التحقق من أن رحلات المستخدم تعمل) وأداة مثل Delta-QA لاختبارات الانحدار البصري (التحقق من أن الواجهة لم تتغير). يكمل كلاهما الآخر بشكل مثالي — أحدهما يتحقق من السلوك، والآخر يتحقق من المظهر.
للمزيد من القراءة
- Delta-QA مقابل Playwright: مقارنة صادقة للاختبار البصري في 2026
- Applitools مقابل Percy: مقارنة شاملة لعمالقة الاختبار البصري (2026)
الخلاصة
مواجهة Playwright مقابل Cypress في الاختبار البصري ليست مواجهة حقيقية. يفوز Playwright في الإمكانيات المدمجة ودعم المتصفحات المتعددة والتكامل. يُعوِّض Cypress بمنظومة إضافاته، لكن على حساب التعقيد والاعتماد على أطراف ثالثة.
لكن الدرس الحقيقي ليس هنا. الدرس الحقيقي هو أن كلتا الأداتين مصممتان للمطورين — والاختبار البصري أهم من أن يكون حكرًا على المطورين وحدهم. طالما بقي ضمان الجودة البصرية موضوعًا تقنيًا، سيبقى الاستثمار فيه ناقصًا.
السؤال الصحيح ليس "Playwright أم Cypress؟" بل: "من في فريقي يجب أن يكون قادرًا على إنشاء اختبارات بصرية؟" إذا كانت الإجابة "الجميع"، فلا أحد منهما هو الحل.