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