جعل الاختبارات تتحقق من العمل

يعلن الوكيل أن الخلل قد أُصلح ويضيف اختبارًا. ينجح الاختبار. فتُغلق التذكرة. وبعد أسبوعين، يعود الحادث نفسه إلى بيئة الإنتاج، بالصورة ذاتها. وحين تراجع الـ diff تكتشف أن الاختبار المضاف لا يمر عبر مسار الكود المعني أصلًا: كان يتحقق من أن دالة مجاورة تُرجع قاموسًا. كان سينجح قبل الإصلاح تمامًا كما ينجح بعده. لم يكن لديك يومًا دليل على أن شيئًا ما قد أُصلح، بل مجرد ضوء أخضر ظهر في اللحظة نفسها التي جرى فيها التعديل.

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

اشتراط الأحمر قبل الأخضر

قسّم الطلب إلى مرحلتين صريحتين ضمن الـ prompt نفسه.

المرحلة 1 — لا تُصلح أي شيء. اكتب في tests/test_facturation.py اختبارًا
يعيد إنتاج هذا الخلل: فاتورة بخصم 100 % تعطي إجماليًا قدره
-0.0 بدلًا من 0.0. شغّل pytest والصق لي مخرجات الفشل.

المرحلة 2 — انتظر موافقتي قبل تعديل كود الإنتاج.