Комментарии 9
Что насчет integration_test? flutter driver с декабря 2020 deprecated.
Имхо, выносить UI в отдельные классы нужно сразу Finder'ами, а не строками.
Что подразумеваете под медленной работой? Сколько тестов и сколько времени? Зачастую решением является integration_test.
С беком тоже спорно, неужели он настолько медленный? Авторизация занимает от силы секунду. Ваш скролл ленты занимает куда больше :). Плюс так можно смотреть не отвалилась ли связка бек+фронт, а моки лучше на виджет тестах смотреть. Их делаете, кстати, или разработчики?
Неважно насколько быстрый бэк - in-memory mock всегда быстрее. Тем более я не считаю, что эти тесты должны проверять работу бэка. Для этого проводится regress и smoke тестирование.
В нашем случае авторизация проходит по 4-м экранам и занимает ~2 секунды. А количество тестов постоянно растет, поэтому если можно сделать быстрее, то почему бы и нет. К тому же в статье пример с авторизацией - это в первую очередь пример использования функционала Flutter Driver.
А где это написано что флаттер драйвер депрекейтед? Я так понимаю, только внутреннее тестирование самого флаттер сдк теперь делается не через флаттер драйвер, а через интеграционный драйвер. А сам флаттер драйвер живее всех живых, развивается и получает багфиксы.
В документации на docs.flutter.dev даже гайд уже не найти на flutter_driver. То что он поддерживается это правда, но вот развивается - вряд ли, т.к. явно активно продвигается переход на него. Да и смысла оставаться на driver кроме как поддержке большого количества тестов нет. И то, можно перенести за недельку если захотеть.
А вы гитхаб по нему смотрели? Как раз он и развивается. Ваша integration_test полностью построена на Flutter Driver. И перевести тесты за недельку не получится, если тесты солидные. Драйвер позволяет сделать значительно больше операций с приложением, чем integration_test, если применять data handler функцию, кастомные файндеры и кастомные команды.
значительно больше операций с приложением, чем integration_test
Пример пожалуйста, может я чего-то не знаю. Контрпример вам: как произвести нажатие на submit кнопку клавиатуры при вводе через flutter_driver?
Ваша integration_test полностью построена на Flutter Driver
Тоже неверно. Единственное что там взято от flutter_driver это получение данных по завершении прогона. Собственно когда эти данные не нужны, интеграционные тесты выполняются командой flutter test. Если ошибаюсь - укажите конкретно какая часть integration_test "полностью построена" на flutter_driver.
Что за сабмит кнопка клавиатуры? Если вы имеете ввиду использовать кнопки клавиатуры - то легче легкого через кастомные команды:await prober.sendKeyEvent(LogicalKeyboardKey.backspace, platform: Platform.operatingSystem)
Если нужно нажать, когда какой-то виджет под фокусом, то тоже легко, просто проверяем фокус виджета по файндеру перед отправкой ивента.
Если вы судите о драйвере толко по бывшей документации, то вы не знаете и трети его возможностей. Разработчики флаттера сами упоминали, что документация устарела. Зато можно найти обширные комментарии в исходниках драйвера на гитхабе.
А вот скажите мне, как в солидном приложении (не на каком то лэндинге, а именно на веб приложении с бэком и фронтом, множественными БД, огромной структурой ивентов, и построенном Bloc паттерне с кубитами) используя интеграционные тесты присоединиться к работающему приложению в нужный момент, когда все остальные части системы выстроены в нужный порядок, и запустить тест?
Интеграционное тестирование всегда было в флатере и существовало вместе с драйвером. Драйвер - именно для системных тестов, когда нужно чтобы все системы работали так, как будут работать у конечного пользователя на девайсе. Интеграционное тестирование проверяет только работу виджетов под влиянием максимум очень небольшого количества внешних факторов. Они никогда не смогут привести систему к тому состоянию, к какому будут приводить системные тесты затрагивающие все аспекты продукта.
Я описывал кастомные команды здесь:
https://medium.com/p/44df0286922b
Плохо что очень мало людей в мире полезло копаться в исходниках драйвера и разобралось в этом подходе. Ещё хуже, что почти никто об этом не писал.
Более того, у меня драйвер во время теста даже записывает сколько ресурсов компьютера использует каждый класс, функция и переменная, как часто они вызываются, как быстро отрабатывают и всё это под капотом, никак не влияя на код других тестировщиков. Это просто невозможно сделать в интеграционном тесте, так как в них тестирование производительности направлено только на скорость отрисовки виджета вне системы, и при паттерне Bloc даже эти данные далеко не всегда верные.
И это я ещё не упоминаю массу программ написанных мною для ручного тестирования, которые во время системного теста на лету помогают менять любые параметры запущенного флаттер приложения не перезапуская его - будь то мобильное или браузерное и генерить необходимые ивенты и стейты.
У интеграционных тестов подобного функционала нету даже в задумке и драйвер тесты невозможно перевести на интеграционные. Потому как это разные уровни тестирования.
Если вы имеете ввиду использовать кнопки клавиатуры
Речь о конкретной кнопке Android/iOS по тапу на которую происходит, например, авторизация. Она обычно справа от пробела, и в LogicalKeyboardKey я не нашел ее. Enter не сработает. Если это выполнимо, супер.
используя интеграционные тесты присоединиться к работающему приложению в нужный момент, когда все остальные части системы выстроены в нужный порядок, и запустить тест?
Интеграционные тесты так же запускаются с начального рута как и тесты под драйвером. Разница только в том как они управляются. Это же не виджет тесты где мы грузим только один виджет. Грузится все приложение, и работает оно абсолютно аналогично реальному или тому что под драйвером. Единственное что проще общаться с виджетами. Какой у вас подход для файндеров которые используют свойства виджетов? Интересно насколько это сложно реализовать. Или просто в теле теста как получить информацию из виджета, не суть. По умолчанию такого файндера в flutter_driver нет, поэтому интересно.
Признаюсь что не сильно копался в driver т.к. на тот момент вышел integration_test, а он и пошустрее, и писать удобнее, поэтому на разборки с драйвером не было времени. Кстати как решаете проблему скорости? Драйвер все таки явно помедленнее чем integration_test.
По ссылке которую я указал - есть пара статей. Не очень красиво написано, но возможности кастомных команд и файндеров там представлены. С приложением из флаттер драйвера можно сделать всё, вплоть до вставить свой виджет в бегущее приложение, изменить логику текущих виджетов, и т.д.
Драйвер не стартует вместе с приложением. Так было написано в официальной документации. Но если покопаться в коде, то можно увидеть что драйвер может присоединиться к уже бегущему приложению на любом этапе.
У нас так тесты реализованы, питон работает через апиум с девайсами запуская, удаляя приложения на флатере. После того как флаттер приложение запущено, питон запускает процесс тестирование через флатер, дергается только один необходимый тест. При необходимости после теста приложение можно удалить, или ничего не делать и запустить любой другой драйвер тест с этого же места.
Скорость, как у селениума на браузере, даже быстрее, ведь дарт быстрее питона и работает с родной виртуальной машиной обсерватори значительно лучше. В общей картине разница в скорости с интеграционными тестами отсутствует так как веб запросы между бэекэндом и фронтом выполняются значительно дольше чем сама прослойка драйвера и драйвер экстеншина.
Я свой путь в дарт начал именно через флаттер драйвер, но из-за специфических тербований к своим тестам перелопатил все исходники самого драйвера и нашёл там массу интересных фич, которые никогда не были описаны в документации.
С кастомными файндерами и командами разобраться не тяжело. Нужно написать 3-4 команды и принцип будет понятен. Суть в том, что рядовые тестировщики продолжают работать с драйвером, как и написано в документации. А те у кого с программированием получше - создают дополнительные команды для драйвера, функционал которых раскрывается на стороне приложения, что даёт полный доступ к исходникам приложения и рантайму.
В итоге, скажем тестировщик говорит что ему нужна команда для клика по аналоговым часам в приложении в зависимости от того сколько часов и минут он указал. На стороне приложения вы создаёте пакет для импорта, где описываете свою новую команду (текстовый вид команды и и параметры которые в неё будут переданы). И в самом приложении вы создайте файл с функционалом для этой команды, где и будут выполнены все расчёты и операции через prober (здесь код больше стает похож на интеграционный тест). После чего эта команда сериализует результат и отправляет драйверу в тест где тестировщик продолжит работать с результатом.
Жаль что эта функциональность никогда не была добавлена в документацию, да и комментарии к коду содержат ошибки, но всё же я разобрался и заставил это работать. И это просто божественная фича. Драйвер из бесполезности становится просто божественным инструментом через который я могу делать ВСЁ как с приложением так и с системой где бежит приложение, без каких либо ограничений.
Flutter: автоматизация UI тестирования