Veai a montré comment tester un agent IA dans JetBrains IDE sans dépendance du modèle

Veai рассказала, как выстроила UI-тесты для своего ИИ-агента внутри JetBrains IDE так, чтобы проверки не зависели от капризов языковой модели. Команда разделила тестирование интерфейса, бизнес-логики и самой LLM, а затем собрала из этого стабильный пайплайн для PR и ночных прогонов.

Почему это сложно

Главная проблема таких продуктов в том, что один и тот же запрос к LLM может вернуть разные формулировки, длину ответа и даже разный формат вывода. Если проверять ИИ-плагин как обычный чат-бот и ждать конкретный текст, UI-тесты быстро превращаются в лотерею. При этом значительная часть продукта вполне детерминирована: настройки пользователя, переходы между состояниями чата, кнопки, бейджи навыков, история диалогов и внутренняя бизнес-логика плагина.

Именно эту часть Veai и решила вынести в отдельный слой автоматизации. Команда исходит из простого принципа: качество ответа модели и работоспособность интерфейса — это разные задачи, и смешивать их в одном тесте не стоит. В проекте уже были проверки на других уровнях, включая тесты модели IDE, сценарии для разных LLM-провайдеров и отдельный агентский бенчмарк.

Поэтому UI-автоматизация стала верхушкой тестовой пирамиды, а не попыткой заменить все остальное. Такой подход важен для IDE-плагина: агент отвечает и в окне чата, и через терминал, а значит число мест, где тест может случайно зафлапать, заметно выше, чем у обычного веб-интерфейса.

Как устроили тесты Чтобы не путать цели, Veai разделила прогоны на несколько режимов.

Smoke-тесты идут в каждом pull request и проверяют базовую работоспособность интерфейса без реального вызова LLM. Full-прогоны запускаются ночью, работают уже с настоящим сервером и проходят всю цепочку от плагина до ответа модели. Отдельно существует benchmark: это не UI-тесты, а оценка пользовательских сценариев и качества работы агента по принципу LLM-as-a-Judge. В результате команда быстрее ловит регрессии в UI днем и не теряет сквозную проверку продукта ночью.

• Smoke в каждом PR: проверка UI и базовой логики без нагрузки на LLM Full ночью: работа с реальным сервером и ожидание ответа в интерфейсе Benchmark отдельно: оценка сценариев агента и качества результата * Параллельный запуск по разным IDE: более широкое покрытие без роста ручной рутины В полном прогоне разработчики используют очень короткий запрос — 2+2=? Ответь покороче. Но цель теста не в том, чтобы увидеть именно число 4. Смысл в другом: после нужных предусловий агент должен выйти в состояние Ready, получить ответ от сервера, корректно достримить токены и показать результат в интерфейсе. Такой сценарий проверяет не креативность модели, а то, что связка IDE-плагина, сервера лицензий, LLM-сервера и внутренних библиотек не развалилась после очередного изменения.

«Мы не стремимся получить ответ 4».

Что помогло в CI С технической стороны Veai опирается на библиотеки JetBrains Starter и Driver.

Starter подготавливает IDE, настраивает тестовый проект и собирает артефакты прогона, а Driver работает с реальным интерфейсом и позволяет описывать элементы через Page Object и DSL-подход. Если локаторов не хватает, команда добавляет accessibleName в продуктовый код или корректирует правила обфускации, чтобы элементы оставались доступными для поиска. Часть состояния вообще подготавливается заранее через XML-настройки плагина, поэтому тестам не нужно каждый раз проходить Welcome-экран и онбординг.

Еще один важный элемент — доступ к внутреннему состоянию IDE через JMX. Это дает возможность не только кликать по интерфейсу, но и проверять, что реально записалось в чат агента, какой провайдер выбран и как выглядит JSON-состояние с точки зрения плагина. Для CI команда держит матрицу из разных версий IntelliJ Platform, нескольких JetBrains IDE, feature flags и обфусцированных сборок.

Тяжелые проверки гоняются ночью, на Linux используется Xvfb, а для снижения шума включены ограниченные ретраи: не больше одного перезапуска теста и не больше трех падений на весь запуск. Практический эффект уже заметен: несколько десятков UI-тестов покрывают настройки плагина, переходы между состояниями чата, вызовы skills, историю диалогов и вход нового пользователя. За первые месяцы такие проверки нашли вполне прикладные баги: после добавления drag and drop файлов ломался copy and paste, прогресс-бар контекста учитывал не всех LLM-провайдеров, выбор агента на UI тоже работал не для всех конфигураций, а сценарий восстановления после ошибки начал визуально мигать вместе с тестами.

Ночные прогоны даже подсветили нестабильность одной из тестовых конфигураций LLM-сервера.

Что это значит

Для продуктов с ИИ-функциями это хороший ориентир: не стоит заставлять UI-тесты судить о качестве модели там, где достаточно проверить устойчивость интерфейса и цепочки интеграций. Разделение детерминированной и недетерминированной частей системы делает тесты быстрее, полезнее и заметно честнее как для разработчиков, так и для QA.