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

Почему ИИ-агентам нужно нечто большее, чем код выхода

Большинство ИИ-ассистентов относятся к запуску Cypress как к любому другому инструменту командной строки: они выполняют npx cypress run, считывают код выхода процесса и решают, прошел тест или нет. Код выхода сообщает агенту, что что-то пошло не так, но он не дает никаких подсказок о том, была ли допущена опечатка в селекторе, не загрузилась ли страница или не перекрыла ли кнопку какая-то плашка (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 и всеми соответствующими атрибутами элементов на тот момент.

Вооружившись этим снимком, ИИ может рассуждать о том, почему селектор не сработал, продолжала ли загружаться страница или модальное окно перекрывало цель. Затем он может предложить изменение кода, применить его и перезапустить тот же spec-файл, чтобы проверить исправление.

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

Чтобы цикл не стал бесконечным, команда Cypress предлагает дисциплинированный рабочий процесс:

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

Агент также должен генерировать объяснение на естественном языке о том, что он заметил и почему предложенное исправление должно сработать. Простого прохождения теста недостаточно; ИИ должен продемонстрировать, что он понял визуальные доказательства.

Кто получит выгоду

Разработчики, которые уже полагаются на ИИ-ассистентов для генерации кода, теперь могут предоставить этим ассистентам более богатую среду для отладки. Ожидаемый эффект — сокращение времени, затрачиваемого на борьбу с нестабильными (flaky) тестами, особенно в крупных наборах сквозных (end-to-end) тестов, где ручное воспроизведение ошибки может занимать минуты. Команды, внедрившие tap, могут добиться более быстрого выполнения pull requests, затрагивающих UI-компоненты, и снизить потребность в длительных сессиях отладки.

Риски и ограничения

Tap все еще находится в стадии бета-тестирования, а это значит, что в нем могут быть ошибки, может измениться синтаксис команд или поддержка определенных конфигураций может быть прекращена без уведомления. Зависимость от открытого интерфейса (open UI) исключает использование headless-конвейеров CI, поэтому командам потребуется отдельная стратегия для автоматизированных сборок. Поскольку функция передает данные DOM в реальном времени, возникают небольшие накладные расходы на производительность, которые могут замедлить выполнение крупных spec-файлов. Наконец, политика безопасности предполагает, что ИИ сможет соблюдать временные рамки и остановиться после одного изменения; плохо спроектированный агент все равно может войти в бесконечный цикл или применить неверное исправление.

За чем следить дальше

  • Циклы обратной связи в бета-версии — Cypress, скорее всего, уточнит JSON-схему и добавит более детализированные команды на основе отзывов первых пользователей.
  • Интеграция с CI — Ожидайте появления скриптов от сообщества, которые свяжут требование tap к режиму open с headless-раннерами, возможно, путем запуска виртуального дисплея.
  • Инструментарий для ИИ-агентов — Разработчики ИИ-ассистентов для написания кода могут начать включать поддержку tap в качестве модуля отладки по умолчанию, что сделает эту функцию более заметной в популярных расширениях для IDE.

Если вы экспериментируете с поддержкой тестов на базе ИИ, попробуйте использовать tap на одном нестабильном (flaky) тесте и посмотрите, сократит ли визуальный контекст цикл отладки. Инструмент не заменит человеческое суждение, но он даст вашему ИИ-агенту «пару глаз», которых ему раньше не хватало.