فحص بصري يقيس DOM بدل أن يقارن الصور

الطريقة الشائعة في الفحص البصري هي مقارنة لقطات الشاشة: تلتقط صورة مرجعية، وتقارن كل تشغيل بها، وتسمح بفارق بكسلات معين.

جرّبتها، ثم تخليت عنها بعد ثلاث مشاكل.

لماذا تركت مقارنة الصور

الصور المرجعية تحتاج صيانة مستمرة. يكفي تغيير مقصود واحد في التصميم حتى تبطل عشرات الصور دفعة واحدة، وبينما أنت مشغول بتحديثها تمر أخطاء حقيقية من غير أن تلاحظها.

ثم إن الاختبارات تصير هشّة. فرق بسيط في تنعيم الخطوط بين جهازك وخادم البناء يكفي لإسقاط اختبارات لا علاقة لها بأي خطأ فعلي.

والمشكلة الأكبر: الصورة لا تعرف ما الذي تنظر إليه. فارق عشرين بكسلا قد يكون ظلا تغيّر موضعه، وقد يكون زرا فقد نصف كلمته، والمقارنة تعاملهما بالطريقة نفسها.

ما بنيته بدلا منها

فحص يفتح الصفحة ويسأل العناصر عن نفسها:

el.scrollWidth > el.clientWidth   // النص أكبر من مكانه، أي أنه مقصوص
document.elementFromPoint(x, y)   // هل العنصر فعلاً في المقدمة؟
getComputedStyle(el).letterSpacing // تباعد حروف على نص عربي

الحادثة التي أثبتت الفرق

شحنت لوحة إدارة فيها قائمة إجراءات، وكانت كل الفحوص خضراء: لا تمرير أفقي ولا أخطاء console. حتى الترجمة كانت سليمة ذهابا وإيابا.

فتحها المالك فوجد أزرارا تقرأ «سُد» و«حذ». خمسة أزرار مقصوصة إلى حرفين.

مقارنة الصور كانت ستكشف الخطأ لو وجدت صورة مرجعية لتلك الشاشة بذلك المحتوى تحديدا. الفحص بالقياس كشفه بسطر واحد، من قاعدة تعمل على كل شاشة من غير أي صورة مرجعية:

clipped label [['سُدد بتحويل بنكي', 118, 28], ['حذف بيانات العميل (PDPL)', 165, 98]]

الرقمان هما العرض الذي يحتاجه النص والعرض المتاح له. زر يحتاج 118 بكسل أُعطي 28.

ما يكشفه هذا ولا تكشفه الصور

يكشف أي تسمية مقصوصة أينما وقعت في الصفحة، والعنصر المرسوم الذي غطاه عنصر آخر فصار خارج متناول النقر. ويلتقط كذلك letter-spacing المطبق على نص عربي، وهو يقطع وصل الحروف من غير أن يظهر في صورة مصغرة.

ما تكشفه الصور ولا يكشفه هذا

التغيرات الجمالية: لون أو ظل تغيّر، أو تباعد اختلّ ميزانه. إن كان هذا ما تحميه في مشروعك فالصور أداة مناسبة.

الخلاصة

الصور تجيب عن سؤال: هل تغيّر الشكل؟ والقياس يجيب عن سؤال آخر: هل ما زالت الواجهة قابلة للاستعمال والقراءة؟ وفي عملي يتكرر السؤال الثاني أكثر بكثير.

اقرأ أيضا