Для текстовой - да, для мультимодальной - нет. А у основных моделей типа опуса, и чат гпт мультимодльный вход, поддерживающий как текст так и изображения. Да и логи никогда не смогут описать в полной мере то, что отрендерилось на экране.
Даже если представить, что можно добавить лог на что угодно, то заранее никогда не знаешь какие логи понадобятся, а логировать вообще все сразу заранее нереально.
Получается, что опять сталкиваемся с циклом боли: написать тест, собрать, получить ошибку, добавить логи на эту ошибку, собрать заново, если снова ошибка, или логов не достаточно, то снова пересобирать.
Testwire дает агенту возможность в рантайме дорабатывать тест, использовать hot reload/hot restart для перезапуска. Это позволяет ему видеть стейт приложения в конкретный момент времени, на котором зафейлился шаг теста, делать скрины, подключаться по Dart MCP к VM, просматривать дерево виджетов, иметь намного большие кол-во инструментов для дебага, чем только логи. На сложных тестах, логов может быть не достаточно чтобы понять почему тест не срабатывает и быстро (или даже медленно) исправить проблему.
Для аналогии можно привести сравнение разработки с использованием hot reload/hot restart, дев тулами с разработкой где только AOT билд и логи
Спасибо за обратную связь! Если я вас правильно понял и речь об аномалиях в самих тестах, то это хороший пойнт: на большем объёме такое легко можно пропустить. На данном этапе решаем это с помощью код-ревью - сначала сабагентом, потом человеком
Для текстовой - да, для мультимодальной - нет. А у основных моделей типа опуса, и чат гпт мультимодльный вход, поддерживающий как текст так и изображения. Да и логи никогда не смогут описать в полной мере то, что отрендерилось на экране.
Даже если представить, что можно добавить лог на что угодно, то заранее никогда не знаешь какие логи понадобятся, а логировать вообще все сразу заранее нереально.
Получается, что опять сталкиваемся с циклом боли:
написать тест,
собрать,
получить ошибку,
добавить логи на эту ошибку,
собрать заново,
если снова ошибка, или логов не достаточно, то снова пересобирать.
Testwire дает агенту возможность в рантайме дорабатывать тест, использовать hot reload/hot restart для перезапуска. Это позволяет ему видеть стейт приложения в конкретный момент времени, на котором зафейлился шаг теста, делать скрины, подключаться по Dart MCP к VM, просматривать дерево виджетов, иметь намного большие кол-во инструментов для дебага, чем только логи. На сложных тестах, логов может быть не достаточно чтобы понять почему тест не срабатывает и быстро (или даже медленно) исправить проблему.
Для аналогии можно привести сравнение разработки с использованием hot reload/hot restart, дев тулами с разработкой где только AOT билд и логи
Да, понял, о чём вы. Спасибо, что поделились примером. Для browser automation это действительно звучит как отдельный слой валидации поведения
Спасибо за обратную связь! Если я вас правильно понял и речь об аномалиях в самих тестах, то это хороший пойнт: на большем объёме такое легко можно пропустить. На данном этапе решаем это с помощью код-ревью - сначала сабагентом, потом человеком