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 это действительно звучит как отдельный слой валидации поведения
Спасибо за обратную связь! Если я вас правильно понял и речь об аномалиях в самих тестах, то это хороший пойнт: на большем объёме такое легко можно пропустить. На данном этапе решаем это с помощью код-ревью - сначала сабагентом, потом человеком