По ссылке которую я указал - есть пара статей. Не очень красиво написано, но возможности кастомных команд и файндеров там представлены. С приложением из флаттер драйвера можно сделать всё, вплоть до вставить свой виджет в бегущее приложение, изменить логику текущих виджетов, и т.д. Драйвер не стартует вместе с приложением. Так было написано в официальной документации. Но если покопаться в коде, то можно увидеть что драйвер может присоединиться к уже бегущему приложению на любом этапе.
У нас так тесты реализованы, питон работает через апиум с девайсами запуская, удаляя приложения на флатере. После того как флаттер приложение запущено, питон запускает процесс тестирование через флатер, дергается только один необходимый тест. При необходимости после теста приложение можно удалить, или ничего не делать и запустить любой другой драйвер тест с этого же места.
Скорость, как у селениума на браузере, даже быстрее, ведь дарт быстрее питона и работает с родной виртуальной машиной обсерватори значительно лучше. В общей картине разница в скорости с интеграционными тестами отсутствует так как веб запросы между бэекэндом и фронтом выполняются значительно дольше чем сама прослойка драйвера и драйвер экстеншина.
Я свой путь в дарт начал именно через флаттер драйвер, но из-за специфических тербований к своим тестам перелопатил все исходники самого драйвера и нашёл там массу интересных фич, которые никогда не были описаны в документации.
С кастомными файндерами и командами разобраться не тяжело. Нужно написать 3-4 команды и принцип будет понятен. Суть в том, что рядовые тестировщики продолжают работать с драйвером, как и написано в документации. А те у кого с программированием получше - создают дополнительные команды для драйвера, функционал которых раскрывается на стороне приложения, что даёт полный доступ к исходникам приложения и рантайму.
В итоге, скажем тестировщик говорит что ему нужна команда для клика по аналоговым часам в приложении в зависимости от того сколько часов и минут он указал. На стороне приложения вы создаёте пакет для импорта, где описываете свою новую команду (текстовый вид команды и и параметры которые в неё будут переданы). И в самом приложении вы создайте файл с функционалом для этой команды, где и будут выполнены все расчёты и операции через prober (здесь код больше стает похож на интеграционный тест). После чего эта команда сериализует результат и отправляет драйверу в тест где тестировщик продолжит работать с результатом.
Жаль что эта функциональность никогда не была добавлена в документацию, да и комментарии к коду содержат ошибки, но всё же я разобрался и заставил это работать. И это просто божественная фича. Драйвер из бесполезности становится просто божественным инструментом через который я могу делать ВСЁ как с приложением так и с системой где бежит приложение, без каких либо ограничений.
Что за сабмит кнопка клавиатуры? Если вы имеете ввиду использовать кнопки клавиатуры - то легче легкого через кастомные команды: await prober.sendKeyEvent(LogicalKeyboardKey.backspace, platform: Platform.operatingSystem)
Если нужно нажать, когда какой-то виджет под фокусом, то тоже легко, просто проверяем фокус виджета по файндеру перед отправкой ивента.
Если вы судите о драйвере толко по бывшей документации, то вы не знаете и трети его возможностей. Разработчики флаттера сами упоминали, что документация устарела. Зато можно найти обширные комментарии в исходниках драйвера на гитхабе.
А вот скажите мне, как в солидном приложении (не на каком то лэндинге, а именно на веб приложении с бэком и фронтом, множественными БД, огромной структурой ивентов, и построенном Bloc паттерне с кубитами) используя интеграционные тесты присоединиться к работающему приложению в нужный момент, когда все остальные части системы выстроены в нужный порядок, и запустить тест?
Интеграционное тестирование всегда было в флатере и существовало вместе с драйвером. Драйвер - именно для системных тестов, когда нужно чтобы все системы работали так, как будут работать у конечного пользователя на девайсе. Интеграционное тестирование проверяет только работу виджетов под влиянием максимум очень небольшого количества внешних факторов. Они никогда не смогут привести систему к тому состоянию, к какому будут приводить системные тесты затрагивающие все аспекты продукта.
Плохо что очень мало людей в мире полезло копаться в исходниках драйвера и разобралось в этом подходе. Ещё хуже, что почти никто об этом не писал.
Более того, у меня драйвер во время теста даже записывает сколько ресурсов компьютера использует каждый класс, функция и переменная, как часто они вызываются, как быстро отрабатывают и всё это под капотом, никак не влияя на код других тестировщиков. Это просто невозможно сделать в интеграционном тесте, так как в них тестирование производительности направлено только на скорость отрисовки виджета вне системы, и при паттерне Bloc даже эти данные далеко не всегда верные.
И это я ещё не упоминаю массу программ написанных мною для ручного тестирования, которые во время системного теста на лету помогают менять любые параметры запущенного флаттер приложения не перезапуская его - будь то мобильное или браузерное и генерить необходимые ивенты и стейты.
У интеграционных тестов подобного функционала нету даже в задумке и драйвер тесты невозможно перевести на интеграционные. Потому как это разные уровни тестирования.
А вы гитхаб по нему смотрели? Как раз он и развивается. Ваша integration_test полностью построена на Flutter Driver. И перевести тесты за недельку не получится, если тесты солидные. Драйвер позволяет сделать значительно больше операций с приложением, чем integration_test, если применять data handler функцию, кастомные файндеры и кастомные команды.
А где это написано что флаттер драйвер депрекейтед? Я так понимаю, только внутреннее тестирование самого флаттер сдк теперь делается не через флаттер драйвер, а через интеграционный драйвер. А сам флаттер драйвер живее всех живых, развивается и получает багфиксы.
По ссылке которую я указал - есть пара статей. Не очень красиво написано, но возможности кастомных команд и файндеров там представлены. С приложением из флаттер драйвера можно сделать всё, вплоть до вставить свой виджет в бегущее приложение, изменить логику текущих виджетов, и т.д.
Драйвер не стартует вместе с приложением. Так было написано в официальной документации. Но если покопаться в коде, то можно увидеть что драйвер может присоединиться к уже бегущему приложению на любом этапе.
У нас так тесты реализованы, питон работает через апиум с девайсами запуская, удаляя приложения на флатере. После того как флаттер приложение запущено, питон запускает процесс тестирование через флатер, дергается только один необходимый тест. При необходимости после теста приложение можно удалить, или ничего не делать и запустить любой другой драйвер тест с этого же места.
Скорость, как у селениума на браузере, даже быстрее, ведь дарт быстрее питона и работает с родной виртуальной машиной обсерватори значительно лучше. В общей картине разница в скорости с интеграционными тестами отсутствует так как веб запросы между бэекэндом и фронтом выполняются значительно дольше чем сама прослойка драйвера и драйвер экстеншина.
Я свой путь в дарт начал именно через флаттер драйвер, но из-за специфических тербований к своим тестам перелопатил все исходники самого драйвера и нашёл там массу интересных фич, которые никогда не были описаны в документации.
С кастомными файндерами и командами разобраться не тяжело. Нужно написать 3-4 команды и принцип будет понятен. Суть в том, что рядовые тестировщики продолжают работать с драйвером, как и написано в документации. А те у кого с программированием получше - создают дополнительные команды для драйвера, функционал которых раскрывается на стороне приложения, что даёт полный доступ к исходникам приложения и рантайму.
В итоге, скажем тестировщик говорит что ему нужна команда для клика по аналоговым часам в приложении в зависимости от того сколько часов и минут он указал. На стороне приложения вы создаёте пакет для импорта, где описываете свою новую команду (текстовый вид команды и и параметры которые в неё будут переданы). И в самом приложении вы создайте файл с функционалом для этой команды, где и будут выполнены все расчёты и операции через prober (здесь код больше стает похож на интеграционный тест). После чего эта команда сериализует результат и отправляет драйверу в тест где тестировщик продолжит работать с результатом.
Жаль что эта функциональность никогда не была добавлена в документацию, да и комментарии к коду содержат ошибки, но всё же я разобрался и заставил это работать. И это просто божественная фича. Драйвер из бесполезности становится просто божественным инструментом через который я могу делать ВСЁ как с приложением так и с системой где бежит приложение, без каких либо ограничений.
Что за сабмит кнопка клавиатуры? Если вы имеете ввиду использовать кнопки клавиатуры - то легче легкого через кастомные команды:
await prober.sendKeyEvent(LogicalKeyboardKey.backspace, platform: Platform.operatingSystem)Если нужно нажать, когда какой-то виджет под фокусом, то тоже легко, просто проверяем фокус виджета по файндеру перед отправкой ивента.
Если вы судите о драйвере толко по бывшей документации, то вы не знаете и трети его возможностей. Разработчики флаттера сами упоминали, что документация устарела. Зато можно найти обширные комментарии в исходниках драйвера на гитхабе.
А вот скажите мне, как в солидном приложении (не на каком то лэндинге, а именно на веб приложении с бэком и фронтом, множественными БД, огромной структурой ивентов, и построенном Bloc паттерне с кубитами) используя интеграционные тесты присоединиться к работающему приложению в нужный момент, когда все остальные части системы выстроены в нужный порядок, и запустить тест?
Интеграционное тестирование всегда было в флатере и существовало вместе с драйвером. Драйвер - именно для системных тестов, когда нужно чтобы все системы работали так, как будут работать у конечного пользователя на девайсе. Интеграционное тестирование проверяет только работу виджетов под влиянием максимум очень небольшого количества внешних факторов. Они никогда не смогут привести систему к тому состоянию, к какому будут приводить системные тесты затрагивающие все аспекты продукта.
Я описывал кастомные команды здесь:
https://medium.com/p/44df0286922b
Плохо что очень мало людей в мире полезло копаться в исходниках драйвера и разобралось в этом подходе. Ещё хуже, что почти никто об этом не писал.
Более того, у меня драйвер во время теста даже записывает сколько ресурсов компьютера использует каждый класс, функция и переменная, как часто они вызываются, как быстро отрабатывают и всё это под капотом, никак не влияя на код других тестировщиков. Это просто невозможно сделать в интеграционном тесте, так как в них тестирование производительности направлено только на скорость отрисовки виджета вне системы, и при паттерне Bloc даже эти данные далеко не всегда верные.
И это я ещё не упоминаю массу программ написанных мною для ручного тестирования, которые во время системного теста на лету помогают менять любые параметры запущенного флаттер приложения не перезапуская его - будь то мобильное или браузерное и генерить необходимые ивенты и стейты.
У интеграционных тестов подобного функционала нету даже в задумке и драйвер тесты невозможно перевести на интеграционные. Потому как это разные уровни тестирования.
А вы гитхаб по нему смотрели? Как раз он и развивается. Ваша integration_test полностью построена на Flutter Driver. И перевести тесты за недельку не получится, если тесты солидные. Драйвер позволяет сделать значительно больше операций с приложением, чем integration_test, если применять data handler функцию, кастомные файндеры и кастомные команды.
А где это написано что флаттер драйвер депрекейтед? Я так понимаю, только внутреннее тестирование самого флаттер сдк теперь делается не через флаттер драйвер, а через интеграционный драйвер. А сам флаттер драйвер живее всех живых, развивается и получает багфиксы.