أطلقت Cypress ميزة تجريبية (beta) تسمى tap تتيح لوكلاء البرمجة المدعومين بالذكاء الاصطناعي (AI-driven coding agents) الاتصال بجلسة اختبار Cypress مباشرة، وسحب لقطات من الـ DOM وسجلات الأوامر، واستخدام هذه المعلومات المرئية لتشخيص حالات الفشل. تعمل هذه الأداة فقط مع إصدار Cypress 15.21.0 أو أحدث، ومتصفح يعتمد على Chromium، وواجهة المستخدم "cypress open"؛ وهي لا تعمل في وضع headless.

لماذا يحتاج وكلاء الذكاء الاصطناعي إلى ما هو أكثر من رمز الخروج (exit code)

تعامل معظم مساعدي البرمجة بالذكاء الاصطناعي تشغيل Cypress كأي أداة سطر أوامر أخرى: حيث يقومون بتشغيل npx cypress run وقراءة حالة الخروج للعملية، ثم يقررون ما إذا كان الاختبار قد نجح أم لا. يخبر رمز الخروج الوكيل بأن شيئاً ما قد سار بشكل خاطئ، لكنه لا يقدم أي دليل عما إذا كان هناك خطأ في كتابة المحدد (selector)، أو فشل في تحميل الصفحة، أو إذا كان هناك عنصر متراكب (overlay) يحجب زراً ما. في المقابل، يقوم البشر بفتح واجهة مستخدم Cypress، ومراقبة المتصفح، وفحص شجرة الـ DOM، وقراءة سجل الأوامر قبل صياغة فرضية.

تلك الفجوة تجعل تصحيح الأخطاء الآلي هشاً. فقد ينتج عن رسالة "Element not found" عشرات الأسباب الجذرية، وبدون دليل مرئي، قد يستمر الذكاء الاصطناعي في محاولة نفس الإصلاح، مما يؤدي إلى الدخول في حلقة مفرغة لا تنتهي.

كيف تسد tap هذه الفجوة

تنشئ tap واجهة تعتمد على الطرفية (terminal) للوصول إلى نسخة Cypress قيد التشغيل. بمجرد أن يقوم المطور بتشغيل Cypress في وضع "open":

npx cypress open --e2e --browser=chrome

يمكن للوكيل إصدار سلسلة من الأوامر ذات المخرجات بتنسيق JSON من shell منفصل:

  • npx cypress tap specs --json – يسرد ملفات الـ spec المتاحة.
  • npx cypress tap run <spec> --json – يبدأ تشغيل ملف spec واحد.
  • npx cypress tap status --json – يعيد حالة التشغيل الحالية، بما في ذلك الطوابع الزمنية.

نظرًا لأن حمولة الحالة (status payload) تحتوي على طابع زمني startedAt ، يمكن للوكيل التحقق من أنه ينظر إلى نتائج حديثة بدلاً من تشغيل قديم انتهى في وقت سابق. لم يعد الاعتماد على رمز الخروج الخام وحده كافياً.

عند فشل الاختبار، يمكن للوكيل التعمق أكثر:

  • npx cypress tap reporter --json – يجلب تقرير الاختبار العام.
  • npx cypress tap command --test-id <ID> --command-id <ID> --json – يسحب الأمر الدقيق الذي حدث فيه الخطأ، جنباً إلى جنب مع لقطة لشجرة الـ DOM الخاصة بالتطبيق، وشجرة ARIA، وأي سمات عناصر ذات صلة في تلك اللحظة.

بناءً على تلك اللقطة، يمكن للذكاء الاصطناعي الاستنتاج حول سبب فشل المحدد، أو ما إذا كانت الصفحة لا تزال قيد التحميل، أو ما إذا كان هناك مربع حوار (modal) يحجب الهدف. يمكنه بعد ذلك اقتراح تغيير في الكود، وتطبيقه، ثم إعادة تشغيل نفس ملف الـ spec للتحقق من الإصلاح.

سياسة أمان للوكلاء المستقلين

لمنع الدخول في حلقة لا تنتهي، يقترح فريق Cypress سير عمل منضبطاً:

  1. تشغيل ملف spec واحد محدد فقط.
  2. فحص tap status بمهلة زمنية صارمة، مع تجاهل أي نتيجة يكون فيها startedAt أقدم من آخر عملية فحص.
  3. فحص الاختبار الفاشل والأمر المسبب للخطأ فقط.
  4. السماح بتعديل واحد فقط على الكود قبل التشغيل التالي.
  5. إعادة تشغيل الـ spec.
  6. إذا تغيرت النتيجة، توقف وقم بإخطار بشري للمراجعة.

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

من المستفيد؟

يمكن للمطورين الذين يعتمدون بالفعل على مساعدي الذكاء الاصطناعي لتوليد الكود الآن تزويد هؤلاء المساعدين بسطح تصحيح أخطاء أغنى. الفائدة المتوقعة هي تقليل الوقت المستغرق في ملاحقة الاختبارات غير المستقرة (flaky tests)، خاصة في مجموعات الاختبارات الشاملة (end-to-end suites) الكبيرة حيث يمكن أن يستغرق إعادة إنتاج الفشل يدوياً عدة دقائق. قد تشهد الفرق التي تتبنى tap سرعة أكبر في إنجاز طلبات السحب (pull requests) التي تمس مكونات واجهة المستخدم، وحاجة أقل لجلسات تصحيح الأخطاء المتبادلة.

المخاطر والقيود

لا تزال tap في المرحلة التجريبية (beta)، مما يعني أنها قد تحتوي على أخطاء، أو يتغير بناء أوامرها، أو تتوقف عن دعم بعض الإعدادات دون إشعار. إن اعتمادها على واجهة المستخدم المفتوحة يستبعد خطوط أنابيب CI التي تعمل في وضع headless، لذا ستحتاج الفرق إلى استراتيجية منفصلة لعمليات البناء الآلية. ونظراً لأن الميزة تقوم ببث بيانات DOM مباشرة، فهناك عبء إضافي بسيط على الأداء قد يؤدي إلى إبطاء ملفات الـ specs الكبيرة. أخيراً، تفترض سياسة الأمان أن الذكاء الاصطناعي يمكنه احترام المواعيد النهائية والتوقف بعد تغيير واحد؛ ومع ذلك، يمكن لوكيل مصمم بشكل سيئ أن يدخل في حلقة مفرغة أو يطبق إصلاحاً غير صحيح.

ما الذي يجب مراقبته لاحقاً

  • دورات ملاحظات النسخة التجريبية – من المرجح أن تقوم Cypress بتحسين مخطط JSON وإضافة أوامر أكثر دقة بناءً على مدخلات المستخدمين الأوائل.
  • التكامل مع CI – توقع ظهور سكربتات من المجتمع تعمل على الربط بين متطلبات وضع التشغيل المفتوح (open-mode) لـ tap وبين المشغلات عديمة الواجهة (headless runners)، ربما عن طريق إنشاء عرض افتراضي.
  • أدوات الوكلاء المعتمدين على الذكاء الاصطناعي – قد تبدأ الشركات المطورة لمساعدي البرمجة في تضمين دعم tap كـ وحدة تصحيح أخطاء افتراضية، مما يجعل هذه الميزة أكثر ظهوراً في إضافات بيئات التطوير المتكاملة (IDE) الشائعة.

إذا كنت تجرب صيانة الاختبارات المدفوعة بالذكاء الاصطناعي، فجرّب tap على حالة اختبار (spec) واحدة غير مستقرة (flaky) وانظر ما إذا كان السياق المرئي سيقلل من دورة تصحيح الأخطاء. لن تحل هذه الأداة محل التقدير البشري، لكنها تمنح وكيل البرمجة الخاص بك "عينين" لم تكن لديه من قبل.