Сколько я не пытаюсь понять идеи KAspresso, мне это не удаётся. Есть Espresso и UIAutomator, которые и так используются внутри. Абсолютно всё описанное делается чисто на них.
При том, что я тоже написал свой "фреймворк" - а на самом деле обёртку над Эспрессо и ЮайАвтоматором. Просто для унификации API и всяких совсем типовых задач. При этом у себя я сохранил совместимость с фреймворками Гугла, чтобы, при необходимости, мой можно было выбросить за 1 день.
Не получится виртуально протестировать функционал VPN, GPS, прохождение девайс-специфичных FRW и сценариев и многое другое.
А какие фичи VPN не протестировать на эмуляторе, кроме скорости и батарейки? Почему на эмуляторе не протестировать GPS? `geo fix` же есть. Какие специфичные сценарии FRW нельзя проверить? Уж чего-чего, а проверка разных разрешений и плотностей — это прям то, для чего эмулятор создан. Кстати, FRW - это не общепринятое, мне кажется. Я тоже привык говорить FRW или PIW, но в новой команде меня не понимали, пока не объяснил расшифровку.
Так мы пришли к идее фермы на OpenSTF
Да, я понимаю, что это привычка так называть. Но уточню для тех, кто читал статью для того, чтобы узнать новое:
OpenSTF больше не существует. Проект заброшен и не сопровождается. Сейчас сопровождением занимается DeviceFarmer: https://github.com/DeviceFarmer
Сопровождение от ДевайсФермер тоже такое себе. Оно именно сопровождение — поддержали новую версию Андроида и на том спасибо. Проблемы, которым тысяча лет - например, нестабильное управление по REST API или принудительный откат состояния устройства - не исправляются
Если у вас используется Appium, то, во-первых, я вам сочувствую, а во-вторых ДевайсФерма требует древнющей версии node.js (8-ой), тогда как Аппиум - свежей. Так что вы обязаны будете растаскивать их по разным контейнерам, в одной системе они не могут сосуществовать. Ну а если Аппиум не используете, то и не начинайте
А если растащите по докер контейнерам (в любом случае придётся из-за нод.жс, так что правильнее сказать "когда"), то учтите, что ферму нужно будет заставить использовать хостовой adb (благо это одна строчка в конфиге докера), иначе, если вы этого не сделаете, хостовой будет конфликтовать с тем, что в контейнере фермы. И добавляем сюда адб из аппиума... Возможно это и можно разрулить безболезненно, но я просто выбросил к чертям Аппиум, потому что он не нужен примерно ни для чего (в моём мире)
функционале
Таки "функциональность". Функционал - это из математики и из ЛГБТ (но это не точно). Хотя ты и техподдержку называешь саппортом, так что ладно :)
за исключением, пожалуй, теста на потребление заряда батареи
Таки проводное подключение по adb - это один из способов. Вы точно также могли бы подключать устройства и без провода.
Коллеги из других отделов свободно проверяют локализацию продуктов, тестируют дизайн. ... Аналогично можно проверить, насколько дизайн адаптирован к супермаленькому экрану.
И снова это задачи для эмулятора. Более того, никто не запрещает подключить эмулятор к ферме. Я сам планирую так сделать, но сейчас есть причины этого не делать в моём проекте. Через пару релизов подключу.
У нас есть «дежурный» по ферме, который может быстро подключить необходимый девайс.
То есть физическое присутствие. Я планирую вообще избавиться от такого подхода. Ну и хочу опробовать usb over tcp. Интересно, будет ли выигрыш в производительности при отладке.
Для размещения устройств мы используем металлический телеком-шкаф
Вот тут я вообще не понял. Вы же клетку фарадея сделали. Вы должны иметь лютые проблемы работы беспроводных сетей. Или вы не закрываете дверцу? Или нет задней стенки?
BC 1.2 для зарядки
ВС - это что?
Мы их забираем и складываем в БД MS SQL
Ух, чувствуется подход тырпрайза. Если БД, то жЫрная, если сетевой хаб, то циска. При том, что можно было бы собирать всё в sqlite, что намного проще. Прям несравнимо проще :) Но тырпрайз, понимаю.
Кстати, опасения относительно того, что в таком режиме работы аккумуляторы будут массово вспучиваться, не оправдались.
Ну так у батареек контроллеры умненькие. Я планирую у себя прикрутить ограничение зарядки в 70%, чтобы увеличить срок жизни батарейки
Задаю вопрос не с 13, потому что это всё-таки рабочий день и с 13 до 20 я работаю.
Какую роль выполняет Каспрессо, я так и не понял, честно говоря. Посмотрел примеры отсюда github.com/KasperskyLab/Kaspresso и всё равно не понял. В пример много строчек (правда из-за скобок), которые делают в итоге полтора действия.
Вот код, который сейчас у меня под рукой:
/**
* Пин запрашивается после сворачивания по Home при включенном блоке на сворачивании
*/
@Test
fun pinLockByCollapse() {
enablePin(withCollapse = true)
mUiDevice.pressDeviceHomeButton(false)
mUiDevice.clickPassphraseUnlockedNotification()
mPinLockScreen.verifyEnterPinInLockScreen()
}
Здесь гораздо меньше строк и гораздо больше проверок. Каждая из этих строк делает полные проверки экранов, всех элементов, то есть тут десятки проверок. Зачем бы мне завязываться на внешний фреймворк, по которому нет вообще никаких гарантий? Типа, завтра из компании уйдёт человек, который вот этим рулит и проект будет заброшен и быстро устареет.
Что касается взаимодействия и распараллеливания, то для этого достаточно несколько строчек на питоне (прошу прощения у не знаю кого, ибо на начало написания тех скриптов я ещё не ведал, что творил) или го (сейчас наступаю на те же грабли, но на новом языке :)) и тесты будут гоняться одновременно на любом количестве устройств, а также будут работать e2e тесты между несколькими устройствами одновременно.
При этом сопровождение будет несоизмеримо легче, потому что каждый дополнительный фреймворк тащит с собой дополнительные ошибки и проблемы обновлений. В случае ошибок частенько бывает так, что тестировщик напишет какой-то костыль, который её обходит. Через сколько-то времени выходит новая версия с исправлением, но никто не читает все изменения, потому что некогда, и костыли не убирают и так они остаются мусором. Сквозь этот мусор через несколько лет продираются совершенно другие люди со словами «ну и нафига, ведь и так всё работает нормально».
А ещё возникает проблема обновления, когда зависимости не обновляют по несколько лет, а потом ррраз! И ничего не работает, всё сдохло, нужно теперь разбираться с каждой отдельной проблемой, коих тут вагон. Каждый androidTestImplementation приносит свои проблемы и люди стараются в итоге как можно дольше не обновлять зависимости. Что в итоге выливается в полную неработоспособность системы, когда обновление всё-таки приходится делать.
В общем, я не понимаю сути Каспрессо, его преимуществ. Можете объяснить скептику? Только, пожалуйста, не нужно ставить в преимущества фреймворка Page Object, потому что это не является его заслугой.
Ну и вопрос общий. Как вы выбираете, тянуть какую-то библиотеку в проект или нет? Скажем, вот есть офигенный RxJava, давайте его тащить, без него жизни нет. А тут бах и корутины. Оставляем эрыкс? А зачем? Убираем? А зачем тащили? А не боитесь, что очередная библиотека притащит с собой уязвимость, о которой не предполагали? Притащили, скажем, библиотеку для отображения svg на Андроид 1.2, а потом выяснилось, что если на /sdcard/ лежит файл debug-template-lib-test.svg, то либа пытается вгрузить этот файл, чем бы он на самом деле ни был. Не боитесь такого?
Эпол сделал круто и с помпой презентовал. В итоге китайцы разблокируют телефоны друг друга, дети разблокируют телефоны родителей. То есть эта игрушка просто нежизнеспособна. Так что Гугл, в общем-то, правильно сделал — показал, что это бред собачий. Чтобы ложных надежд не было.
Надо было ещё Самсунгу после фейла Нокии с УЗ сканером отпечатков пальцев тоже признать, что это игрушка, а не защита.
Зачем им Play нужен будет? Карты, почта — есть. Ютуб — хтмл5 приложение запилить за полдня и ещё за пару недель отловить баги. Наполняемость магазина такова, что сам магазин существует. Раз существует, то сам Яндекс это устраивает.
Упомянутый, зачем-то, Самсунг свою ОС сбацал и продаёт в Индии.
Если бы в Яндексе были заняты не нытьём, а работой, я лично бы перешёл на Я.Караты, я бы пользовался почтой, я бы даже погоду смотрел.
В пальце заноза? Почему эта заноза чужая, мы хотим добавить своих заноз!
Так я уже выбрал — взял смартфон не от Яндекс. Если бы желал Яндекс, взял бы на Яндекс.Ките. Что не так? Зачем кто-то желает усложнить мне на лишние движения пальца жизнь моего Гугл-устройства?
Кое-кто наехал на Гугл за новости и взвыли те, чьи интересы «защищались». Как бы не взвыли пользователи Android, сознательно выбирающие именно сервисы Google. Я, например.
Простите, Яндекс, но качество ваших продуктов находится на уровне «проходим по критериям релиза — значит в релиз». И если меня, как пользователя, заставят настраивать мои Android устройства, увеличив количество шагов мастера первоначальной настройки, добавив россыпь галок «Мне нужен тулбар и реклама за мои же деньги, потраченные на не дешёвый аппарат (рекомендуется)», я буду расстроен и буду немного зол на вас.
Но на самом деле не имеет значения, какой именно это Виктор. Важен сам итог — компании детектируют модуль и это будет происходить на всех поделках с этим модулем. Таким образом достигнута одна из целей.
[05.02.2015 11:01] Я: habrahabr.ru/post/249765/
[05.02.2015 11:01] Я: Детектим?
[05.02.2015 11:01] Victor: да
[05.02.2015 11:02] Я: Всё с этим модулем или каждое отдельно? :)
[05.02.2015 11:02] Victor: всё с этим модулем
[05.02.2015 11:02] Я: Отлично, спасибо
Так что да, автор правильно поступил, что сообщил всем, кому нужно было сообщить.
Сколько я не пытаюсь понять идеи KAspresso, мне это не удаётся. Есть Espresso и UIAutomator, которые и так используются внутри. Абсолютно всё описанное делается чисто на них.
При том, что я тоже написал свой "фреймворк" - а на самом деле обёртку над Эспрессо и ЮайАвтоматором. Просто для унификации API и всяких совсем типовых задач. При этом у себя я сохранил совместимость с фреймворками Гугла, чтобы, при необходимости, мой можно было выбросить за 1 день.
И да. adb install -g
Привет, Дим!
А какие фичи VPN не протестировать на эмуляторе, кроме скорости и батарейки? Почему на эмуляторе не протестировать GPS? `geo fix` же есть. Какие специфичные сценарии FRW нельзя проверить? Уж чего-чего, а проверка разных разрешений и плотностей — это прям то, для чего эмулятор создан. Кстати, FRW - это не общепринятое, мне кажется. Я тоже привык говорить FRW или PIW, но в новой команде меня не понимали, пока не объяснил расшифровку.
Да, я понимаю, что это привычка так называть. Но уточню для тех, кто читал статью для того, чтобы узнать новое:
OpenSTF больше не существует. Проект заброшен и не сопровождается. Сейчас сопровождением занимается DeviceFarmer: https://github.com/DeviceFarmer
Сопровождение от ДевайсФермер тоже такое себе. Оно именно сопровождение — поддержали новую версию Андроида и на том спасибо. Проблемы, которым тысяча лет - например, нестабильное управление по REST API или принудительный откат состояния устройства - не исправляются
Если у вас используется Appium, то, во-первых, я вам сочувствую, а во-вторых ДевайсФерма требует древнющей версии node.js (8-ой), тогда как Аппиум - свежей. Так что вы обязаны будете растаскивать их по разным контейнерам, в одной системе они не могут сосуществовать. Ну а если Аппиум не используете, то и не начинайте
А если растащите по докер контейнерам (в любом случае придётся из-за нод.жс, так что правильнее сказать "когда"), то учтите, что ферму нужно будет заставить использовать хостовой adb (благо это одна строчка в конфиге докера), иначе, если вы этого не сделаете, хостовой будет конфликтовать с тем, что в контейнере фермы. И добавляем сюда адб из аппиума... Возможно это и можно разрулить безболезненно, но я просто выбросил к чертям Аппиум, потому что он не нужен примерно ни для чего (в моём мире)
Таки "функциональность". Функционал - это из математики и из ЛГБТ (но это не точно). Хотя ты и техподдержку называешь саппортом, так что ладно :)
Таки проводное подключение по adb - это один из способов. Вы точно также могли бы подключать устройства и без провода.
И снова это задачи для эмулятора. Более того, никто не запрещает подключить эмулятор к ферме. Я сам планирую так сделать, но сейчас есть причины этого не делать в моём проекте. Через пару релизов подключу.
То есть физическое присутствие. Я планирую вообще избавиться от такого подхода. Ну и хочу опробовать usb over tcp. Интересно, будет ли выигрыш в производительности при отладке.
Вот тут я вообще не понял. Вы же клетку фарадея сделали. Вы должны иметь лютые проблемы работы беспроводных сетей. Или вы не закрываете дверцу? Или нет задней стенки?
ВС - это что?
Ух, чувствуется подход тырпрайза. Если БД, то жЫрная, если сетевой хаб, то циска. При том, что можно было бы собирать всё в sqlite, что намного проще. Прям несравнимо проще :) Но тырпрайз, понимаю.
Ну так у батареек контроллеры умненькие. Я планирую у себя прикрутить ограничение зарядки в 70%, чтобы увеличить срок жизни батарейки
Задаю вопрос не с 13, потому что это всё-таки рабочий день и с 13 до 20 я работаю.
Какую роль выполняет Каспрессо, я так и не понял, честно говоря. Посмотрел примеры отсюда github.com/KasperskyLab/Kaspresso и всё равно не понял. В пример много строчек (правда из-за скобок), которые делают в итоге полтора действия.
Вот код, который сейчас у меня под рукой:
Здесь гораздо меньше строк и гораздо больше проверок. Каждая из этих строк делает полные проверки экранов, всех элементов, то есть тут десятки проверок. Зачем бы мне завязываться на внешний фреймворк, по которому нет вообще никаких гарантий? Типа, завтра из компании уйдёт человек, который вот этим рулит и проект будет заброшен и быстро устареет.
Что касается взаимодействия и распараллеливания, то для этого достаточно несколько строчек на питоне (прошу прощения у не знаю кого, ибо на начало написания тех скриптов я ещё не ведал, что творил) или го (сейчас наступаю на те же грабли, но на новом языке :)) и тесты будут гоняться одновременно на любом количестве устройств, а также будут работать e2e тесты между несколькими устройствами одновременно.
При этом сопровождение будет несоизмеримо легче, потому что каждый дополнительный фреймворк тащит с собой дополнительные ошибки и проблемы обновлений. В случае ошибок частенько бывает так, что тестировщик напишет какой-то костыль, который её обходит. Через сколько-то времени выходит новая версия с исправлением, но никто не читает все изменения, потому что некогда, и костыли не убирают и так они остаются мусором. Сквозь этот мусор через несколько лет продираются совершенно другие люди со словами «ну и нафига, ведь и так всё работает нормально».
А ещё возникает проблема обновления, когда зависимости не обновляют по несколько лет, а потом ррраз! И ничего не работает, всё сдохло, нужно теперь разбираться с каждой отдельной проблемой, коих тут вагон. Каждый androidTestImplementation приносит свои проблемы и люди стараются в итоге как можно дольше не обновлять зависимости. Что в итоге выливается в полную неработоспособность системы, когда обновление всё-таки приходится делать.
В общем, я не понимаю сути Каспрессо, его преимуществ. Можете объяснить скептику? Только, пожалуйста, не нужно ставить в преимущества фреймворка Page Object, потому что это не является его заслугой.
Ну и вопрос общий. Как вы выбираете, тянуть какую-то библиотеку в проект или нет? Скажем, вот есть офигенный RxJava, давайте его тащить, без него жизни нет. А тут бах и корутины. Оставляем эрыкс? А зачем? Убираем? А зачем тащили? А не боитесь, что очередная библиотека притащит с собой уязвимость, о которой не предполагали? Притащили, скажем, библиотеку для отображения svg на Андроид 1.2, а потом выяснилось, что если на /sdcard/ лежит файл debug-template-lib-test.svg, то либа пытается вгрузить этот файл, чем бы он на самом деле ни был. Не боитесь такого?
Надо было ещё Самсунгу после фейла Нокии с УЗ сканером отпечатков пальцев тоже признать, что это игрушка, а не защита.
Всё названное я могу делать, используя только adb. И даже могу пинать через него своё espresso приложение, дёргая нужные прямо сейчас классы.
А ответ мне даётся на какой-то другой вопрос, который я, вроде, не задавал.
Ненавижу видео. Можно раскрыть его здесь? Чтобы я мог задавать уточняющие вопросы, чтобы мог использовать поиск, чтобы мог цитировать.
Зачем вообще нужен любой сторонний фреймворк при работе с adb? Что там происходит такого, чего я не могу сделать сам, используюя только adb?
inb4: фильм «Клетка» / The Cell
Упомянутый, зачем-то, Самсунг свою ОС сбацал и продаёт в Индии.
Если бы в Яндексе были заняты не нытьём, а работой, я лично бы перешёл на Я.Караты, я бы пользовался почтой, я бы даже погоду смотрел.
В пальце заноза? Почему эта заноза чужая, мы хотим добавить своих заноз!
1. Берёт AOSP
2. Вкорячивает свои сервисы
3. Распространяет
Что должен сделать Яндекс?
1. Взять AOSP
2. Вкорячить свои сервисы
3. Распространять
Что реально делает Яндекс?
1. Родил мертвеца на 2 телефона
2. Ноет
Простите, Яндекс, но качество ваших продуктов находится на уровне «проходим по критериям релиза — значит в релиз». И если меня, как пользователя, заставят настраивать мои Android устройства, увеличив количество шагов мастера первоначальной настройки, добавив россыпь галок «Мне нужен тулбар и реклама за мои же деньги, потраченные на не дешёвый аппарат (рекомендуется)», я буду расстроен и буду немного зол на вас.
Но на самом деле не имеет значения, какой именно это Виктор. Важен сам итог — компании детектируют модуль и это будет происходить на всех поделках с этим модулем. Таким образом достигнута одна из целей.
[05.02.2015 11:01] Я: Детектим?
[05.02.2015 11:01] Victor: да
[05.02.2015 11:02] Я: Всё с этим модулем или каждое отдельно? :)
[05.02.2015 11:02] Victor: всё с этим модулем
[05.02.2015 11:02] Я: Отлично, спасибо
Так что да, автор правильно поступил, что сообщил всем, кому нужно было сообщить.