ما الذي يحتاج فعلاً إلى اختبار UI
المسار يعمل من طرف إلى طرف. يستطيع المستخدم الانتقال من النية إلى النتيجة. ولا شيء تحت الواجهة يمكنه الإجابة عن هذا.
الحالة عبر الخطوات. ما يُضبط في شاشة يُحترم في الشاشة التالية. وهنا تتجمّع العيوب الحقيقية.
ما يُقال للمستخدم يطابق ما حدث. رسالة نجاح بلا سجل محفوظ هي أشهر كذبة يقولها التطبيق.
ما لا ينتمي إلى اختبار UI
قواعد التحقق
تجربة كل تركيبة من المدخلات الخاطئة عبر المتصفح بطيئة وهشّة.
تحقّق من واحدة في UI، والبقية عند API.
الحسابات
اختبار الوحدة يجيب عن هذا في ميلي ثوانٍ، وبرسالة فشل أفضل.
تهيئة البيانات
النقر عبر خمس شاشات لإنشاء بيانات تجهيز بطيء، وينكسر لأسباب لا علاقة لها بما تختبره.
تحديد حجم المجموعة
قاعدتان مفيدتان. غطِّ المسارات بحسب مدى صمت فشلها لا بحسب أهميتها، لأن المسارات المهمة مراقَبة أما الصامتة فلا. وتوقّف عن الإضافة حين تبدأ كلفة الصيانة في التهام الوقت الذي كنت توفّره، وهو ما يحدث أبكر مما تتوقع معظم الفرق.
العادات الثلاث
مرتكزات ثابتة، لا مسارات CSS. يزيل معظم الأعطال الناتجة عن إعادة التصميم.
انتظر حالةً، لا وقتًا. يزيل معظم التذبذب.
تحقّق مما تؤكّده إعادة التحميل. يزيل الثقة الزائفة التي تمنحها رسالة النجاح.
دفع الاختبار طبقةً إلى الأسفل، عمليًا
من السهل الموافقة على نصيحة نقل الفحوص إلى ما تحت الواجهة، لكن تطبيقها يبقى غامضًا، وهذا شكلها على مثال حقيقي.
لديك اختبار متصفح يملأ نموذج تسجيل بأربعة عشر مدخلاً غير صالح، ويتحقق من رسالة الخطأ في كل مرة. يستغرق أربع دقائق، وينكسر كلما تغيّر تخطيط النموذج، ولا يخبرك شيئًا يُذكر عن المتصفح.
استبدل به اختبار متصفح واحدًا يرسل مدخلاً غير صالح واحدًا ويؤكّد ظهور خطأ للمستخدم، إلى جانب ثلاثة عشر اختبار API تفحص قواعد التحقق مباشرة. صار اختبار المتصفح يجيب عن سؤال يخص المتصفح، وصارت القواعد مغطّاة بسرعة ودقة أكبر، ولم يعد تغيير قاعدة تحقق يستدعي المساس بأي شيء يُعرض على الشاشة.
الجزء الذي لا يصلحه الانضباط
المحدِّدات
إعادة تصميم لا تغيّر شيئًا في الوظائف تُحوّل المجموعة كلها إلى اللون الأحمر.
هنا يذهب معظم وقت الصيانة فعليًا.
الانتظار
التأخيرات الثابتة بطيئة ومتذبذبة رغم ذلك. والانتظار الصحيح يحتاج إلى معرفة ما الذي ينتظره.
معظم التذبذب يعود إلى هنا.
تغطية يكتبها البشر
تغطّي ما كتبه أحدهم، أي المسارات المثيرة للاهتمام لا تلك التي تنكسر.
الثالثة بنيوية. فالتغطية المقيّدة بوقت من يكتبها ستتخلّف عن منتج يأتي قدر متزايد من شيفرته من وكيل برمجي. والخطوات القائمة على النية والتغطية المولَّدة تعالجان هذا الجزء.
الطرفية
npm install -g @testsprite/testsprite-cli
testsprite setup
تغطي لوحة التحكم المجال نفسه لمن لا يريد تثبيتًا محليًا، وسطح الأوامر الكامل موجود في مستودع CLI.
اربط المستودع من لوحة التحكم لتبدأ عمليات التشغيل من النشر الذي تنتجه أصلاً، أو أضف خطوة إلى سير عملك الخاص بدلاً من ذلك.
ما تغطيه TestSprite في كل طبقة
المسارات في المتصفح، حيث لا يجيب سوى المتصفح، وطبقة API تحتها ضمن المشروع نفسه. وهذا ما يجعل نصيحة الدفع إلى الأسفل عملية لا مجرد أمنية: تنتقل قواعد التحقق إلى حالات API تعمل في ثوانٍ، وتتحقق حالة متصفح واحدة من أن النموذج موصول بها.
كلتاهما مولَّدة من منتجك ويجري صقلها بلغة عادية، وخطوات المتصفح نوايا لا محدِّدات، فتصمد المجموعة أمام إعادات التصميم التي لا تغيّر شيئًا في الوظائف.
ما تنتهي إليه هو مجموعة اختبارات متصفح صغيرة بما يكفي ليثق بها الناس، تغطي الرحلات المهمة، مع تغطية القواعد والحالات الحدّية بسرعة أكبر في الطبقة الأدنى.
كم عدد اختبارات UI المناسب؟
ما يكفي لتغطية الرحلات التي يُحرجك انكسارها، مختارةً بحسب مدى صمت فشلها. وادفع كل ما عداها طبقةً إلى الأسفل.
هل نختبر كل شاشة؟
لا. اختبر المسارات لا الشاشات. والشاشة التي لا يمر بها مسار نادرًا ما تبرّر اختبار متصفح.
وماذا عن إمكانية الوصول؟
تستحق الأتمتة في الفحوص الآلية، وتحتاج إلى مراجعة بشرية فيما عدا ذلك. شأن منفصل له أدواته الخاصة.
هل التغطية عبر عدة متصفحات ضرورية؟
يعتمد ذلك على بيانات التحليلات لديك. كثير من الفرق تشغّل مجموعة كاملة على متصفح واحد ومجموعة فحص سريع على البقية، وهي عادةً المقايضة الصحيحة.
متى ينبغي تشغيل اختبارات UI؟
مع كل طلب سحب. وأي وتيرة أقل من ذلك تعني أن الفشل يشير إلى دفعة من التغييرات لا إلى تغيير واحد.
اختبر المسارات في UI، وكل ما عداها تحتها.
ينبغي أن يغطي اختبار UI المسارات من طرف إلى طرف، والحالة عبر الخطوات، وما إذا كان ما يُقال للمستخدم يطابق ما حدث. أما التحقق والحسابات وتهيئة البيانات فمكانها الطبقة الأدنى، حيث تكون أسرع وأسهل في التشخيص.