Cypress یک ویژگی بتا به نام tap منتشر کرده است که به عوامل کدنویسی مبتنی بر هوش مصنوعی اجازه می‌دهد به یک جلسه تست زنده Cypress متصل شوند، اسنپ‌شات‌های DOM و لاگ‌های دستورات را استخراج کنند و از آن اطلاعات بصری برای تشخیص خطاها استفاده کنند. این ابزار فقط با Cypress نسخه 15.21.0 یا جدیدتر، یک مرورگر مبتنی بر Chromium و رابط کاربری "cypress open" کار می‌کند؛ این ویژگی در حالت headless اجرا نمی‌شود.

چرا عوامل هوش مصنوعی به چیزی فراتر از یک کد خروج نیاز دارند

بیشتر دستیارهای کدنویسی هوش مصنوعی، اجرای Cypress را مانند هر ابزار خط فرمان دیگری در نظر می‌گیرند: آن‌ها دستور npx cypress run را اجرا می‌کنند، وضعیت خروج فرآیند را می‌خوانند و تصمیم می‌گیرند که آیا تست با موفقیت انجام شده یا خیر. یک کد خروج به عامل (agent) می‌گوید که مشکلی پیش آمده است، اما هیچ سرنخی ارائه نمی‌دهد که آیا یک انتخاب‌گر (selector) اشتباه تایپ شده، یک صفحه بارگذاری نشده، یا یک لایه رویی (overlay) مانع کلیک روی دکمه شده است. در مقابل، انسان‌ها رابط کاربری Cypress را باز می‌کنند، مرورگر را تماشا می‌کنند، درخت DOM را بررسی می‌کنند و قبل از ارائه فرضیه، لاگ دستورات را می‌خوانند.

آن شکاف باعث می‌شود عیب‌یابی خودکار شکننده باشد. خطای "Element not found" می‌تواند از ده‌ها علت ریشه‌ای ناشی شود و بدون شواهد بصری، یک هوش مصنوعی ممکن است مدام همان اصلاح را امتحان کند و در یک حلقه بی‌پایان گرفتار شود.

چگونه tap این شکاف را پر می‌کند

Tap یک رابط کاربری مبتنی بر ترمینال برای یک نمونه 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 – وضعیت اجرای فعلی، شامل برچسب‌های زمانی را برمی‌گرداند.

از آنجایی که محتوای وضعیت شامل یک برچسب زمانی startedAt است، عامل می‌تواند تأیید کند که در حال مشاهده نتایج تازه است و نه یک اجرای قدیمی که قبلاً تمام شده است. تکیه کردن تنها به کد خروج خام دیگر کافی نیست.

وقتی یک تست با شکست مواجه می‌شود، عامل می‌تواند عمیق‌تر بررسی کند:

  • npx cypress tap reporter --json – گزارش کلی تست را دریافت می‌کند.
  • npx cypress tap command --test-id <ID> --command-id <ID> --json – دقیقاً همان دستوری را که خطا داده است، به همراه اسنپ‌شاتی از DOM اپلیکیشن، درخت ARIA و هرگونه ویژگی (attribute) مرتبط با المان در آن لحظه استخراج می‌کند.

با داشتن آن اسنپ‌شات، هوش مصنوعی می‌تواند استدلال کند که چرا انتخاب‌گر (selector) عمل نکرده، آیا صفحه هنوز در حال بارگذاری بوده یا آیا یک مودال (modal) مانع هدف شده است. سپس می‌تواند یک تغییر در کد پیشنهاد دهد، آن را اعمال کند و همان spec را دوباره اجرا کند تا اصلاح انجام شده را تأیید نماید.

یک سیاست ایمنی برای عوامل خودگردان

برای جلوگیری از اجرای بی‌پایان حلقه، تیم Cypress یک گردش کار منضبط را پیشنهاد می‌کند:

  1. فقط یک فایل spec خاص را اجرا کنید.
  2. دستور tap status را با یک ضرب‌الاجل (deadline) دقیق بررسی کنید و هر نتیجه‌ای که startedAt آن قدیمی‌تر از آخرین بررسی است را نادیده بگیرید.
  3. فقط تست در حال شکست و دستور مقصر را بررسی کنید.
  4. قبل از اجرای بعدی، تنها اجازه یک اصلاح کد را بدهید.
  5. spec را دوباره اجرا کنید.
  6. اگر نتیجه تغییر کرد، عملیات را متوقف کرده و برای بررسی به یک انسان اطلاع دهید.

عامل همچنین باید یک توضیح به زبان طبیعی از آنچه مشاهده کرده و دلیل کارکرد اصلاح پیشنهادی ارائه دهد. موفقیت در تست کافی نیست؛ هوش مصنوعی باید ثابت کند که شواهد بصری را درک کرده است.

چه کسانی از این ویژگی بهره‌مند می‌شوند

توسعه‌دهندگانی که در حال حاضر برای تولید کد به دستیارهای هوش مصنوعی متکی هستند، اکنون می‌توانند سطح عیب‌یابی غنی‌تری را در اختیار این دستیارها قرار دهند. مزیت مورد انتظار، کاهش زمان صرف شده برای دنبال کردن تست‌های ناپایدار (flaky tests) است، به‌ویژه در مجموعه‌های بزرگ end-to-end که بازتولید دستی یک خطا می‌تواند دقایق طول بکشد. تیم‌هایی که tap را به کار می‌گیرند ممکن است شاهد سرعت بیشتر در بررسی pull requestهایی باشند که با کامپوننت‌های UI در تماس هستند و نیاز کمتری به جلسات عیب‌یابی رفت و برگشتی داشته باشند.

ریسک‌ها و محدودیت‌ها

Tap هنوز در مرحله بتا است، به این معنی که ممکن است حاوی باگ باشد، نحو (syntax) دستوراتش تغییر کند یا پشتیبانی از برخی پیکربندی‌ها را بدون اطلاع قبلی قطع کند. تکیه آن بر رابط کاربری open، خط لوله‌های CI بدون رابط گرافیکی (headless) را مستثنی می‌کند، بنابراین تیم‌ها به استراتژی جداگانه‌ای برای ساخت‌های خودکار (automated builds) نیاز خواهند داشت. از آنجایی که این ویژگی داده‌های زنده DOM را ارسال می‌کند، یک بار اضافی (overhead) عملکردی اندک وجود دارد که می‌تواند سرعت specهای بزرگ را کاهش دهد. در نهایت، سیاست ایمنی فرض را بر این می‌گذارد که هوش مصنوعی می‌تواند به ضرب‌الاجل‌ها احترام بگذارد و پس از یک تغییر متوقف شود؛ یک عامل با طراحی ضعیف همچنان می‌تواند وارد یک حلقه بی‌نهایت شود یا اصلاح اشتباهی را اعمال کند.

آنچه در آینده باید منتظر آن بود

  • چرخه‌های بازخورد بتا – احتمالاً Cypress طرحواره JSON را اصلاح کرده و بر اساس نظرات کاربران اولیه، دستورات دقیق‌تری را اضافه خواهد کرد.
  • یکپارچه‌سازی با CI – انتظار اسکریپت‌های جامعه کاربری را داشته باشید که نیاز tap به حالت open-mode را با اجراکننده‌های headless پل می‌زنند، شاید از طریق ایجاد یک نمایشگر مجازی.
  • ابزارهای عامل هوش مصنوعی (AI-agent) – فروشندگانی که دستیارهای کدنویسی می‌سازند، ممکن است پشتیبانی از tap را به عنوان یک ماژول عیب‌یابی پیش‌فرض ارائه دهند که باعث می‌شود این قابلیت در افزونه‌های رایج IDE بیشتر دیده شود.

اگر در حال آزمایش نگهداری تست مبتنی بر هوش مصنوعی هستید، tap را روی یک spec ناپایدار (flaky) امتحان کنید و ببینید آیا بافت بصری (visual context) چرخه عیب‌یابی را کوتاه‌تر می‌کند یا خیر. این ابزار جایگزین قضاوت انسان نخواهد شد، اما به عامل کدنویسی شما، جفت‌چشمی می‌دهد که پیش از این فاقد آن بود.