Cypress שחררה תכונת בטא בשם tap המאפשרת לסוכני קוד מבוססי AI להתחבר לסשן בדיקה חי של Cypress, למשוך צילומי DOM ויומני פקודות, ולהשתמש במידע הוויזואלי הזה כדי לאבחן כשלים. הכלי עובד רק עם Cypress 15.21.0 ומעלה, דפדפן מבוסס Chromium, וממשק ה-UI של “cypress open”; הוא אינו פועל במצב headless.

למה סוכני AI זקוקים ליותר מקוד יציאה (exit code)

רוב עוזרי הקוד מבוססי ה-AI מתייחסים להרצת Cypress כמו לכל כלי שורת פקודה אחר: הם מריצים npx cypress run, קוראים את סטטוס היציאה של התהליך, ומחליטים אם הבדיקה עברה. קוד יציאה אומר לסוכן שמשהו השתבש, אך הוא אינו מספק רמז האם נפלה טעות הקלדה ב-selector, האם דף נכשל בטעינה, או ששכבה (overlay) חסמה כפתור. בני אדם, לעומת זאת, פותחים את ממשק ה-UI של Cypress, צופים בדפדפן, בוחנים את עץ ה-DOM וקוראים את יומן הפקודות לפני שהם מגבשים השערה.

הפער הזה הופך את ניפוי התקלות (debugging) האוטומטי לשברירי. "Element not found" יכול לנבוע מעשרות סיבות שורש, וללא ראיות ויזואליות, AI עלול להמשיך לנסות את אותו תיקון שוב ושוב, בלופ אינסופי.

איך 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 – שולף את הפקודה המדויקת שגרמה לשגיאה, יחד עם צילום מצב (snapshot) של ה-DOM של האפליקציה, עץ ה-ARIA וכל מאפייני אלמנט רלוונטיים באותו רגע.

כשהוא מצויד בצילום המצב הזה, ה-AI יכול להסיק מדוע ה-selector לא מצא את האלמנט, האם הדף עדיין היה בטעינה, או אם מודאל (modal) הסתיר את היעד. לאחר מכן הוא יכול להציע שינוי בקוד, להחיל אותו, ולהריץ מחדש את אותו spec כדי לוודא שהתיקון עבד.

מדיניות בטיחות לסוכנים אוטונומיים

כדי למנוע מהלופ לרוץ לנצח, צוות Cypress מציע תהליך עבודה ממושמע:

  1. הריצו רק קובץ spec ספציפי אחד.
  2. בצעו polling ל-tap status עם דדליין קשיח, תוך התעלמות מכל תוצאה ש-startedAt שלה ישן יותר מה-poll האחרון.
  3. בדקו רק את הבדיקה שנכשלה ואת הפקודה הבעייתית.
  4. אפשרו שינוי קוד יחיד לפני ההרצה הבאה.
  5. הריצו מחדש את ה-spec.
  6. אם התוצאה השתנתה, עצרו וסמנו בן אדם לבדיקה.

הסוכן צריך גם לייצר הסבר בשפה טבעית על מה שהוא הבחין ומדוע התיקון המוצע אמור לעבוד. מעבר של הבדיקה אינו מספיק; ה-AI חייב להוכיח שהוא הבין את הראיות הוויזואליות.

מי עומד להרוויח מכך

מפתחים שכבר מסתמכים על עוזרי AI ליצירת קוד יכולים כעת להעניק לעוזרים הללו משטח ניפוי תקלות עשיר יותר. התועלת הצפויה היא הפחתה בזמן המושקע במרדף אחרי בדיקות לא יציבות (flaky tests), במיוחד בערכות end-to-end גדולות שבהן שחזור כשל באופן ידני יכול לקחת דקות ארוכות. צוותים שיאמצו את tap עשויים לראות זמן תגובה מהיר יותר על pull requests הנוגעים לרכיבי UI, וצורך נמוך יותר במפגשי ניפוי תקלות הלוך ושוב.

סיכונים ומגבלות

Tap עדיין נמצא בגרסת בטא, מה שאומר שהוא עשוי להכיל באגים, לשנות את תחביר הפקודות שלו, או להפסיק לתמוך בהגדרות מסוימות ללא הודעה מראש. ההסתמכות שלו על ממשק ה-UI הפתוח שוללת צינורות CI במצב headless, כך שצוותים יזדקקו לאסטרטגיה נפרדת עבור בנייה (builds) אוטומטית. מכיוון שהתכונה מזרמת נתוני DOM חיים, ישנה עלות ביצועים (performance overhead) מתונה שעלולה להאט specs גדולים. לבסוף, מדיניות הבטיחות מניחה שה-AI יכול לכבד דדליינים ולעצור לאחר שינוי בודד; סוכן שתוכנן בצורה גרועה עדיין עלול להיכנס ללופ אינסופי או להחיל תיקון שגוי.

מה כדאי לעקוב אחריו בהמשך

  • מחזורי משוב בטא – Cypress ככל הנראה תשכלל את סכימת ה-JSON ותוסיף פקודות מפורטות יותר בהתבסס על קלט ממשתמשים מוקדמים.
  • אינטגרציה עם CI – צפו לסקריפטים מהקהילה שיגשרו בין דרישת ה-open-mode של tap לבין headless runners, אולי באמצעות יצירת תצוגה וירטואלית.
  • כלי עבודה עבור סוכני AI – ספקים המפתחים עוזרי כתיבת קוד עשויים להתחיל לכלול תמיכה ב-tap כמודול debugging ברירת מחדל, מה שיהפוך את התכונה לנראית יותר בתוספי IDE נפוצים.

אם אתם מתנסים בתחזוקת בדיקות מבוססת AI, נסו את tap על flaky spec בודד ובדקו האם ההקשר הוויזואלי מקצר את מחזור ה-debugging. הכלי לא יחליף את שיקול הדעת האנושי, אך הוא אכן מעניק לסוכן הכתיבה שלכם "זוג עיניים" שהיה חסר לו קודם לכן.