اختبار واجهة المستخدم UI باستخدام Puppeteer: الدليل العملي

ما الذي يجيده فعلًا اختبار واجهة المستخدم UI باستخدام Puppeteer

• تحكم مباشر في المتصفح. لقطات الشاشة، وملفات PDF، واعتراض طلبات الشبكة، وتتبّع الأداء. حين تحتاج إلى أن يفعل المتصفح شيئًا بعينه، فهذا أقصر طريق.

• كشط البيانات والأتمتة. جزء كبير من استخدامات Puppeteer ليس اختبارًا على الإطلاق، وهو ممتاز في ذلك.

• واجهة صغيرة يسهل تعلّمها. يمكنك أن تستوعب API كاملةً في ذهنك، وهذا أندر مما ينبغي.

التكاليف الثلاث لمجموعة اختبارات المتصفح

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

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

• التغطية مكتوبة بأيدي البشر. أنت تغطّي ما كتبه أحدهم، أي المسارات التي بدت مثيرة للاهتمام، لا المسارات التي تنكسر.

كيف تقرر ما الذي تؤتمته

الغريزة تدفعك إلى البدء بأهم ميزة. لكن المعيار الأفضل هو مدى صمت العطل حين يقع. انكسار عملية الدفع صاخب، وستسمع عنه خلال ساعة. أما انكسار عملية تصدير أو دعوة أو صفحة إعدادات فصامت، والأعطال الصامتة هي التي تستحق الأتمتة أولًا.

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

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

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

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

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

أين يقع التحقق القائم على النية

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

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

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

الأمور الثلاثة التي تجعل نص Puppeteer البرمجي هشًّا

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

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

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

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

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

إذا كان خط البناء يخص فريقًا آخر، فإن GitHub App هو الطريق الأقل مقاومة: فهو webhook، ولا يغيّر شيئًا في مستودعك، ويُطلَق حين يبلّغ بناؤك بأن النسخة الجديدة صارت على الهواء. وإن كنت تريد أن يظهر الفحص داخل المستودع بدلًا من ذلك، فخطوة في GitHub Actions تؤدي ذلك.

أين يقع TestSprite إلى جانب Puppeteer

يبقى Puppeteer للتحكم المباشر في المتصفح: لقطات الشاشة، وملفات PDF، واعتراض طلبات الشبكة، وكشط البيانات. ويأخذ TestSprite الجزء الذي لا يتوسّع مع وقت من يكتبه، أي تحديد ما يجب تغطيته وإبقاؤه حيًّا.

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

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