الاختبار الآلي لواجهة المستخدم UI: اختر بحسب مدى صمت العطل

معيار اختيار أفضل للاختبار الآلي لواجهة المستخدم UI

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

المعيار الثاني: كم مرة يتغيّر المسار. الشاشة التي يُعاد تصميمها في كل دورة تطوير ستكلّف في الصيانة أكثر مما تعود به. غطِّها بعد أن تستقر.

التكاليف الثلاث

يمكن معالجة الأوليين بالانضباط. أما الثالثة فبنيوية: التغطية المكتوبة يدويًا محكومة بوقت من يكتبها، ووقت الكاتب لا يزداد.

ثلاث عادات تُوفّر أكبر قدر

• ثبّت الاختبارات على سمات مستقرة. سمة مخصّصة للاختبار بدلًا من مسار CSS. هذا وحده يزيل معظم أعطال إعادة التصميم.

• انتظر حالةً، لا وقتًا. انتظر العنصر أو الاستجابة. التأخير الثابت بطيء وغير موثوق في آن واحد.

• تحقّق مما تؤكّده إعادة التحميل. إشعار النجاح المنبثق ليس دليلًا على أن شيئًا قد حُفظ.

لماذا تُحذف مجموعات الاختبار

ليس لأنها لا تجد شيئًا، بل لأن نسبة الإخفاقات الحقيقية إلى إخفاقات الصيانة تسوء إلى حدّ يجعل الناس يتوقفون عن قراءة النتائج. وما إن يصبح البناء الأحمر يعني «غالبًا محدِّد» بدل «غالبًا خلل»، تكون المجموعة قد توقفت عن أداء وظيفتها وإن ظلّت تعمل.

حماية تلك النسبة هي المهمة الحقيقية، وهي تتعلق بكيفية التعبير عن الخطوات أكثر مما تتعلق بعدد الاختبارات لديك.

تغطية لا تعتمد على وقت من يكتبها

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

وتؤدي لوحة التحكم الغرض نفسه لمن لا يريد تثبيتًا محليًا، أما مجموعة الأوامر الكاملة فتجدها في مستودع CLI.

حجم المجموعة الذي يبقى مفيدًا

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

القيد ليس زمن التنفيذ، بل الانتباه. مجموعة من ثلاثين مسارًا تُنتج إخفاقات يذهب أحدهم للتحقيق فيها. ومجموعة من ثلاثمئة تُنتج قائمة يومية، والقوائم تُفرَز ولا تُقرأ. وما إن يبدأ الفرز، يصبح الاختبار الإضافي يضيف ضجيجًا لا تغطية، مهما أُحسِنت كتابته.

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

شغّلها مع كل تغيير

المُشغِّل أهم من الآلية. فتوجيهها إلى حدث النشر لديك يعني فحص كل تغيير دون أن يقرّر أحد ذلك؛ وهذا ما يفعله تطبيق GitHub App من لوحة التحكم، أما خطوة GitHub Actions فتفعله من داخل سير عملك.

أين يغيّر TestSprite الحسابات

التكلفة الثالثة، أي التغطية المحكومة بوقت من يكتبها، هي التي لا يصلحها الانضباط، وهي ما يزيله TestSprite. تُولَّد الحالات من منتجك وتُنقَّح بلغة بسيطة، فتُغطّى المسارات الصامتة دون أن يجد أحد فترة بعد ظهر ليكتبها.

أما التكلفتان الأوليان فتتحسّنان كأثر جانبي. تُخزَّن الخطوات كنوايا لا كمسارات داخل DOM، فإعادة تصميم تنقل زرًّا لا تُحوِّل المجموعة إلى الأحمر، والانتظار مُعالَج أصلًا بدل ضبطه في كل اختبار. وهاتان هما وجهة معظم وقت الصيانة.

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