يُعدّ اختبار لقطات الشاشة طريقة فعّالة للغاية للتحقّق من واجهة مستخدم تطبيقك. يمكن أن توجد اختبارات لقطات الشاشة في اختبارات المكونات والميزات والتطبيق.
يمكنك استخدام أدوات تابعة لجهات خارجية لإنشاء اختبارات لقطات الشاشة المُزوّدة بأدوات اختبار واختبارات لقطات الشاشة المحلية. إذا كنت تستخدم ميزة "الكتابة"، يمكنك استخدام أداة اختبار رسمية لميزة "الكتابة".
التعريف
تأخذ اختبارات لقطات الشاشة لقطة شاشة لواجهة المستخدم وتقارنها بصورة تمت الموافقة عليها سابقًا، وتُعرف باسم "المرجعية" أو "الذهبية":
إذا كانت الصور متطابقة، يجتاز الاختبار. إذا كانت هناك اختلافات بين النسختَين، تنشئ الأداة تقريرًا:
من خلال التقرير، لديك ردّان محتملان:
- إذا لاحظت أنّ هناك خطأ في الرمز الجديد، عليك إصلاحه.
- اعتمد لقطة الشاشة الجديدة واستبدِل الصورة المرجعية بالصورة الجديدة.
تختلف سير العمل في اختبارات لقطات الشاشة عن سير العمل في الاختبارات العادية لأنّ تعذُّر اجتياز أحد الاختبارين لا يعني دائمًا أنّ هناك خطأ.
الإيجابيات
الفوائد أو اختبارات لقطات الشاشة هي:
- يُجري اختبار لقطة الشاشة عمليات تأكيد متعدّدة لكل اختبار. على سبيل المثال، يمكن أن يتحقّق اختبار واحد من الألوان والهوامش والأحجام والخطوط.
- من الأسهل بكثير كتابة اختبار لقطة الشاشة وفهمه والحفاظ عليه مقارنةً باختبار السلوك المعادل.
- وهي مفيدة بشكل خاص عند التحقّق من التراجعات ورصدها على أحجام شاشات مختلفة.
السلبيات
ومع ذلك، يمكن أن يكون لاختبارات لقطات الشاشة أيضًا عيوب:
- قد يكون التعامل مع الصور المرجعية صعبًا، لأنّ المشروع الكبير قد يؤدي إلى إنشاء آلاف ملفات PNG.
- تنتج الأنظمة الأساسية المختلفة (Linux وMax وWindows) لقطات شاشة مختلفة قليلاً.
- وهي أبطأ من اختبارات السلوك المماثلة.
- قد يؤدي إجراء عدد كبير من اختبارات لقطات الشاشة إلى حدوث مشاكل، مثل حدوث مشاكل عندما يؤثر تغيير واحد في آلاف لقطات الشاشة.
تقدّم الأقسام التالية اقتراحات بشأن معالجة هذه المشاكل.
احرص على استخدام الحد الأدنى من اختبارات لقطات الشاشة
يجب تقليل عدد اختبارات لقطات الشاشة مع زيادة الملاحظات والتغطية إلى أقصى حدّ للتراجعات.
يمكن أن تؤدي مجموعات حالات واجهة المستخدم المختلفة إلى زيادة عدد الاختبارات بسرعة كبيرة. في ما يلي بعض الطرق التي يمكنك من خلالها التحقّق من جزء من واجهة مستخدم تطبيقك:
- مواضيع مختلفة
- استخدام أحجام خطوط مختلفة
- داخل أحجام شاشات أو حدود مختلفة
وإذا أجريت ذلك لكل مكوّن وتنسيق وشاشة في تطبيقك، ستحصل على آلاف ملفات لقطات الشاشة، ولن تقدّم لك معظمها أي ملاحظات إضافية.
على سبيل المثال، إذا كنت تريد اختبار زر مخصّص بتنسيقَين فاتحَين وداكنَين، وبثلاثة أحجام للخط، لن تحتاج إلى إنشاء مجموعات من كل هذه العناصر. بدلاً من ذلك، يمكنك اختيار أحد المظاهر فقط. ويرجع ذلك إلى أنّ طريقة تفاعل زر مع الكلمات الطويلة لا تؤثّر في المظهر.
تخزين الصور المرجعية
تكون الصور المرجعية (أو الصور الذهبية) عادةً ملفات بتنسيق PNG يمكن إرسالها إلى أداة التحكّم في المصدر. ومع ذلك، تم تحسين Git ومعظم مدراء التحكّم في المصدر ليعملوا مع الملفات النصية، وليس الملفات الثنائية الكبيرة.
لديك 3 خيارات لإدارة هذه الملفات:
- مواصلة استخدام git، ولكن مع محاولة الحدّ من استخدام مساحة التخزين
- استخدِم Git LFS.
- استخدام إحدى الخدمات السحابية لإدارة لقطات الشاشة
الاختلافات بين المنصات
تعتمد اختبارات لقطات الشاشة على واجهات برمجة تطبيقات منخفضة المستوى للمنصات لرسم ميزات معيّنة، مثل النص أو الظلال، ويمكن للمنصات تنفيذ هذه الميزات بطرق مختلفة. إذا كنت تُجري التطوير على جهاز Mac وتحفظ لقطات شاشة جديدة تم التقاطها على الجهاز، قد تظهر لك اختبارات معطّلة على جهاز Linux CI.
هناك طريقتان لحلّ المشكلة:
- قبول التغييرات الصغيرة
- أخذ لقطات شاشة على خادم
قبول التغييرات الصغيرة
يمكنك ضبط معظم مكتبات اختبار لقطات الشاشة للسماح بالاختلافات الصغيرة عند مقارنة لقطات شاشة.
هناك طريقتان لإجراء ذلك:
- يمكنك ضبط حدّ التسامح استنادًا إلى نسبة مئوية من وحدات البكسل المعدَّلة أو نسبة مئوية من إجمالي الفرق في قيم وحدات البكسل.
- استخدِم أداة ذكية للتمييز، وهي الخوارزمية التي تقارن لقطات الشاشة، للتحقّق من التشابه البنيوي والدلالي بدلاً من وحدات البكسل.
ويتمثل عيب هذا النهج في أنّه قد يؤدي إلى ظهور نتائج إيجابية خاطئة، وعدم رصد الأخطاء التي تكون إما أقل من الحدّ الأدنى أو التي يتم اعتبارها خطأً مشابهة بما يكفي.
أخذ لقطات شاشة على خادم
لاستخدام أداة مقارنة لقطات الشاشة بدقة بكسل، يجب التأكّد من أنّ اختباراتك تلتقط لقطات شاشة في الظروف نفسها. ولإجراء ذلك، يمكنك استخدام نظام التكامل المستمر (CI) أو الاستعانة بخدمة سحابة إلكترونية.
على سبيل المثال، يمكنك إنشاء خطوة في سير عمل التطوير المتكامل (CI) لتنفيذ ما يلي:
- يجري اختبارات لقطات الشاشة (ضرورية فقط في حال عدم استخدام المطابقة التامة بالبكسل).
- يتم تسجيل لقطات شاشة جديدة في حال تعذّر تنفيذ الخطوة السابقة.
- تُرسِل الملفات الجديدة إلى الفرع.
باستخدام هذا النهج، لا تخفق اختبارات لقطات الشاشة أبدًا في CI، ولكنها تؤدي إلى تعديل التغيير نيابةً عنك. بهذه الطريقة، يمكنك أنت ومراجعو التغييرات قبول لقطات الشاشة الجديدة من خلال دمج التغيير.
أدوات اختبار لقطات الشاشة
راجِع الاختلافات الرئيسية التالية بين الأدوات والمكتبات المتاحة لاختبار لقطات الشاشة:
- البيئة: الاختبارات المحلية التي يتم إجراؤها على المضيف، أو الاختبارات التي يتم تجهيزها بأدوات القياس والتي يتم إجراؤها على جهاز محاكاة أو جهاز
- محرّك العرض: يمكن أن تستخدِم حلول لقطات الشاشة من جهة المضيف Layoutlib، وهو محرّك عرض Android IDE للاطّلاع على المعاينات، أو Robolectric Native Graphics (RNG).
- تركّز الأطر المستندة إلى Layoutlib على عرض المكونات الثابتة، باستخدام حالات مختلفة لعرض سلوك مختلف. وعادةً ما تكون أسهل في الاستخدام.
- يمكن لأطر العمل التي تتكامل مع RNG استخدام جميع الميزات من Robolectric، مما يسمح بإجراء اختبارات على نطاق أكبر.