Cypress випустив бета-функцію під назвою tap, яка дозволяє ШІ-агентам програмування підключатися до живої сесії тестування Cypress, отримувати знімки DOM та логи команд, а також використовувати цю візуальну інформацію для діагностики помилок. Інструмент працює лише з Cypress 15.21.0 або новішою версією, браузером на базі Chromium та інтерфейсом «cypress open»; він не працює в headless-режимі.

Чому ШІ-агентам потрібно більше, ніж просто код завершення

Більшість ШІ-помічників ставляться до запуску Cypress як до будь-якого іншого інструменту командного рядка: вони виконують npx cypress run, зчитують статус завершення процесу та вирішують, чи пройшов тест. Код завершення повідомляє агенту, що щось пішло не так, але він не дає жодної підказки, чи була помилка в селекторі, чи сторінка не завантажилася, чи кнопка була заблокована оверлеєм. Люди, навпаки, відкривають інтерфейс 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 – повертає поточний статус виконання, включаючи часові мітки.

Оскільки payload статусу містить часову мітку startedAt, агент може переконатися, що він переглядає свіжі результати, а не застарілий запуск, який завершився раніше. Покладатися лише на сирий код завершення більше недостатньо.

Коли тест не проходить, агент може заглибитися в деталі:

  • npx cypress tap reporter --json – отримує загальний звіт про тести.
  • npx cypress tap command --test-id <ID> --command-id <ID> --json – витягує саме ту команду, яка спричинила помилку, разом зі знімком DOM додатка, ARIA-деревом та будь-якими відповідними атрибутами елементів у цей момент.

Маючи такий знімок, ШІ може зрозуміти, чому селектор не спрацював, чи сторінка все ще завантажувалася, або чи не перекривав модальне вікно цільовий елемент. Після цього він може запропонувати зміну коду, застосувати її та перезапустити той самий spec для перевірки виправлення.

Політика безпеки для автономних агентів

Щоб цикл не тривав вічно, команда Cypress пропонує дисциплінований робочий процес:

  1. Запускайте лише один конкретний spec-файл.
  2. Опитуйте tap status із суворим дедлайном, ігноруючи будь-який результат, чий startedAt старіший за останній запит.
  3. Досліджуйте лише той тест, що не пройшов, і відповідну команду.
  4. Дозволяйте лише одну зміну коду перед наступним запуском.
  5. Перезапустіть spec.
  6. Якщо результат змінився, зупиніться та позначте проблему для перевірки людиною.

Агент також має генерувати пояснення природною мовою про те, що він помітив і чому запропоноване виправлення має спрацювати. Просто пройти тест недостатньо; ШІ має продемонструвати, що він зрозумів візуальні докази.

Хто отримає вигоду

Розробники, які вже покладаються на ШІ-помічників для генерації коду, тепер можуть надати цим помічникам ширші можливості для налагодження. Очікуваною вигодою є скорочення часу, витраченого на боротьбу з нестабільними (flaky) тестами, особливо у великих наборах end-to-end тестів, де ручне відтворення помилки може зайняти хвилини. Команди, які впровадять tap, можуть побачити швидше виконання pull request-ів, що стосуються UI-компонентів, і зниження потреби у багаторазових сесіях налагодження.

Ризики та обмеження

Tap все ще перебуває в стадії бета-тестування, а це означає, що він може містити помилки, змінювати синтаксис команд або припиняти підтримку певних конфігурацій без попередження. Його залежність від відкритого інтерфейсу (open UI) виключає headless CI-конвеєри, тому командам знадобиться окрема стратегія для автоматизованих збірок. Оскільки функція передає дані DOM у реальному часі, існують помірні витрати продуктивності, які можуть сповільнити виконання великих spec-файлів. Нарешті, політика безпеки передбачає, що ШІ зможе дотримуватися дедлайнів і зупинитися після однієї зміни; погано спроектований агент все одно може увійти в нескінченний цикл або застосувати неправильне виправлення.

За чим стежити далі

  • Цикли бета-зворотного зв'язку – Cypress, ймовірно, вдосконалить JSON-схему та додасть більш деталізовані команди на основі відгуків перших користувачів.
  • Інтеграція з CI – Очікуйте на скрипти від спільноти, які поєднуватимуть вимогу tap щодо режиму open-mode з headless-раннерами, можливо, шляхом створення віртуального дисплея.
  • Інструментарій для ШІ-агентів – Розробники асистентів для написання коду можуть почати включати підтримку tap як модуль налагодження за замовчуванням, що зробить цю функцію помітнішою у популярних розширеннях IDE.

Якщо ви експериментуєте з підтримкою тестів за допомогою ШІ, спробуйте tap на одному нестабільному (flaky) тесті та подивіться, чи скоротить візуальний контекст цикл налагодження. Інструмент не замінить людське судження, але він дасть вашому кодинг-агенту «пару очей», яких йому раніше бракувало.