Comments 8
Классный кейс.
Интересно, думали ли вы про следующий уровень проверки - когда агент не только чинит тест до зелёного статуса, но и валидируется с точки зрения поведения (например, что он не кликает 10 раз подряд по одному и тому же элементу, не открывает экран по 3 раза и т.п.)? В браузерной автоматизации это часто отдельный слой поверх обычных интеграционных тестов, чтобы ловить «странное» поведение ещё до продакшена.
Спасибо за обратную связь! Если я вас правильно понял и речь об аномалиях в самих тестах, то это хороший пойнт: на большем объёме такое легко можно пропустить. На данном этапе решаем это с помощью код-ревью - сначала сабагентом, потом человеком
Точно, код-ревью sub-agent + человек - надёжный подход на текущем этапе.
Аномалии в поведении тестов часто вылезают именно при переходе на реальные сценарии. Например, агент кликает идеально по центру элемента 10 раз подряд - логически тест зелёный, но для реального UI (особенно web-based) это флаг для антибота. В browser automation такое ловим отдельной проверкой на human-like паттерны.
Для этого как раз и используем CloakBrowser - он не только патчит fingerprint, но и добавляет behavioral noise (рандом в движении мыши, задержки) на уровне движка. Тогда агентский тест не только проходит, но и не палится как автоматика.
Интеграционные тесты понятно зачем, всегда было понятно, а зачем testwire так и непонятно.
В чём отличие если агент дёрнет тесты, которые либо пасс либо фейл и иди смотри логи там.
Testwire дает агенту возможность в рантайме дорабатывать тест, использовать hot reload/hot restart для перезапуска. Это позволяет ему видеть стейт приложения в конкретный момент времени, на котором зафейлился шаг теста, делать скрины, подключаться по Dart MCP к VM, просматривать дерево виджетов, иметь намного большие кол-во инструментов для дебага, чем только логи. На сложных тестах, логов может быть не достаточно чтобы понять почему тест не срабатывает и быстро (или даже медленно) исправить проблему.
Для аналогии можно привести сравнение разработки с использованием hot reload/hot restart, дев тулами с разработкой где только AOT билд и логи
Как будто бы для текстовой модели основной и конечный источник информации - это текст а не скрины, и если логов недостаточно то нужно улучшать логи.
Для текстовой - да, для мультимодальной - нет. А у основных моделей типа опуса, и чат гпт мультимодльный вход, поддерживающий как текст так и изображения. Да и логи никогда не смогут описать в полной мере то, что отрендерилось на экране.
Даже если представить, что можно добавить лог на что угодно, то заранее никогда не знаешь какие логи понадобятся, а логировать вообще все сразу заранее нереально.
Получается, что опять сталкиваемся с циклом боли:
написать тест,
собрать,
получить ошибку,
добавить логи на эту ошибку,
собрать заново,
если снова ошибка, или логов не достаточно, то снова пересобирать.
ИИ-агенты и Flutter: как сделать интеграционные тесты частью процесса разработки