Спасибо за статью, однако мне очень обидно и сейчас я обьясню почему ;)
Если коротко, то Kaspresso - это фреймворк для автотестирования, сделанный на базе Espresso
Начнем с того, что Kaspresso со всеми PageObjectами опирается не на Espresso а на Kakao, который предоставляет DSL для Espresso, которое под капотом как раз выполняет описанные вами вроде
В Kaspresso есть более богатые возможности работы со стандартными элементами AndroidX. Например в Kaspresso есть KTextInputLayout, которого нам не хватало в библиотеке espresso-page-object и нативном Espresso.
В дополнение к Kakao, Kaspresso как раз предоставляет дополнительный функционал вокруг adb и прочих ништячков
Ах как жаль, что в такой замечательной статье нет ни одного упоминания про Kakao.
С наилучшими пожеланиями, Vacxe, который немножко разбирается в кодовой базе Kakao, Kaspresso и Marathon =)
Вуаля! Так мы не только избавились от того громоздкого и неповоротливого ужаса, но и привнесли мощь RxJava в Presenter.
К сожалению, это ошибочное заблуждение.
Любое разбиение на слои так или иначе добавляет рутинный (boilerplate) код. Крайне часто интеракторы в данной концепции являются прокси между репозиторием и вью уровнями, тогда почему мы их не убирает для «сокращения кода»?
RxJava же по своей сущности является инструментом для планирования бизнес логики, а как следствие должна находиться на уровнях Repository & Interactor Implementation. Interactor Interface должен возвращать интерфейс который отвечает за возврат данных. А возвращая Observable в данной концепции вы теряете логику отвественности в слоях плюс использование Flowable Completable and etc. В чем главная проблема — если вы решите переехать на coroutines предположим, то Presentation layer тоже будет задет. С разделением через интерфейсы — вам будет необходимо изменить реализацию Interaction Impl. И вы сможете плавно выполнить миграцию.
Если вы хотите развлечения, то на уровне бизнес логики вам необходимы атомарные сущности интеракторов (чтение — запись в базу, запросы из веб апи и тд) каждый из которых может быть протестирован независимо, и композиционные сущности которые будут обьединять атомарные в бизнес логику. Да, данный подход будет еще более boilerplate но чистота кода (логическое разделение) обратно пропорциональна усложнению по сущностям.
В заключении — ваш подход весьма спорный и все зависит от обьема проекта, требований на тестирование и тд.
Ну и для наводки на изучение просто оставлю ссылочку на AppCenter CLI. Недавно подпилил им чутка функционала. Для дистрибьюции приложений весьма подходит. В нашем проекте используем его.
К сожалению вы очень сильно заблуждаетесь. В больших компания в которых над каждой платформой трудятся 25+ человек релиз это весьма тяжелая задача. Начиная от тестирования (допустим 25к Unit test + 1к UI test) и цена ошибки крайне велика. Также разработчик не обязан знать что происходит в части маркетинга, а как следствие думать о листингах. Пусть даже это будет изменение раз в квартал — «за эникеить» 38 (локалей) * 6 (скриншотов) * 3 (девайса) = 684 скриншота будет весьма проблематично.
Также релиз процессы зачастую поставлены на поток и происходят раз в неделю, форнайтли или месячно.
Ну и в заключение, не знание про «Badoo» как о компании очень разочаровывает. Ребята делают весьма не плохой вклад в развитие IT — сообщества в целом.
Что касается Android части, для взаимодействия с Google Play API не так уже и много годных вариантов.
Проект от Triple-J с Gradle плагином по мне весьма сомнительное решение так как система сборки не должна знать о дистрибьюции.
Да, есть Java и JS библиотеки, но все они обернуты в какие то специфические кейсы, как например эта
Зачастую требуется единичная задача на CI которая отвечает исключительно за выгрузку APK и mapping (В нашем случае). Грубо говоря есть темплейт задачи в котором лежат все необходимые пароли на прокси и так далее и при создании TCE Build просто переопределяются названия файлов и куда заливать.
На выходных обернули Google Play API (Java) в прозрачный CLI
В ближайшее время сделаем аналог для npm так как есть проблемы с apline
Ну и в заключении, тулинг выбирается под задачу. Спасибо за статью!
Спасибо за статью. Если работаешь автоматизацией тестирования будешь страдать априори. Я конечно понимаю, что уже у вас стабильная система и переписывать ее не имеет смысла исходя из ресурсозатрат но стоит взглянуть на STF (Resources manager) + Marathon (Test orchestrator). Ещё можно сделать автоматический скейл агентов. Предположим у вас капасити на 50 агентов с эмуляторами но если они не используются в течение часа то убиваются. Это позволит очень сильно облегчит ресурсы в ночное время.
За последние 4 года я провел около 300+ интервью. Зачастую на собеседовании нужно идти от обратного. Просто поставить себе цель не «Проверить скилы человека под позицию» а «Оценить уровень». Надо начинать с простых вопросов. Интервью — это стресс для кандидата.
Я обожаю спрашивать самые простые задачи, но они должны быть показательными. Пример: «Посчитать уникальное количество символов в строке. „AABB“ = 2, „ABBA“ = 2, „AAAA“ = 1»
Почему задача показательная? Потому что ее можно решить множеством способов, но чистых будет мало. Большинство (да да 80%), решают данную задачу через «Map» и это странно. Ну да ладно.
Не надо сразу давать вопросы уровня Nightmare. Очень приятно поговорить про базовый уровень, типа сложность коллекций и так далее.
Вам необходимо нащупать тот уровень, где кандидат начинает плавать в вопросах.
Почему это хорошо? Допустим у вас стоит задача найти Senior, а кандидат идет как Intermediate. Возможно в вашей компании есть открытая позиция. Да и зачастую выгоднее взять смышленого Inter`а чем зазнавшегося Senior`a
Ах да, по возможности давайте отзыв о кандидате ему лично. За последние 5 минут, сказать где у него были недочеты и что ему нужно улучшить. «Извини дорогой Джонни, в нашем проекте необходимы знания в А Б В — фреймворках, а ты плохо в них разбираешься. Давай ка ты почитаешь книги от А.Я. Клешня И.Я Клешня, и попробуешь через полгода» — таким образом человек будет знать, в каких областях ему нужно улучшить знания.
Именно это и имел ввиду. Очень часто на собеседование приглашают через реферал. Иногда это помогает пропустить скрининг с эйчаром например. Маленькие плюшечки, но это другая история.
Мне кажется, что есть два основных принципиальных пути в работе: так называемые Work — где, в основном, вам платят за время и Craft — за приобретенный скилл.
Когда я только поступал к институт на САПР, мои школьные друзья уже начинали работать. Да, это была достаточно примитивная работа — продавец консультант, мерчендайзер и т.д. И знаете что, тогда я реально завидовал им. Я думал, что вот они получают 50к рублей и это круто, а у меня стипендия в 5к и стратегический запас дошираков.
Прошло какое то время, у меня появились базовые знания к компьютерных науках (где-то три года, чтобы не забивать на учебу), и я вышел на первую работу. Как сейчас помню, я был крайне рад этим 25к в месяц! Мне давали кодить реальный продукт, я учился у настоящих программистов.
Спустя еще какое то время, я сменил работу уже в направление, которое мне было интересно, и я стал получать 60к в месяц! Но прошло уже 5 лет обучения и опыта. А мои друзья все продолжали делать тоже самое за те же самые деньги. Примерно тогда я понял, что труды окупились.
Прошло еще 5 лет, и я уже два раза успел сменить страну проживания. Если я захочу переехать практически в любой город мира — найти друзей не проблема. Везде сделают референсы, так как огромная сеть коллег. А друзья до сих пор работают продавцами-консультантами.
Стать программистом — достаточно легко в наше время. Быть программистом — скорее призвание. Нельзя без любви к профессии добиться реальных высот. Да и зарплата не является основным мотивирующим фактором.
— Сравнение с водителем автобуса весьма не уместно. В стране где я живу, зарплата водителя автобуса составляет 80к в год, что эквивалентно зарплате мидл программиста. Но проезд на автобусе стоит около 4 долларов. Пересчитаем в эквивалент на рубли (1 доллар вместо 4) — приблизительно 60-70 тысяч в месяц (в Москве), что соответсвует реалиям. Так устроен рынок.
Да. Еще есть вариант пойти работать «держать Lollipop». Это что-то вроде дорожного знака (Stop\Slow) приблизительно за 60к долларов в год. Джуну будут платить примерно также.
Мне кажется, что я первый человек из пост-СССР кто получил разрешение (полное) на полеты в Тайланде.
Для этого было потрачено
1) Страховка — порядка 70 баксов (30 минут)
2) Регистрация как телекомуникационного устройства — бесплатно (45 минут)
3) Регистрация в СААТ — бесплатно (около трех месяцев!)
Спасибо за редактирование, теперь намного понятнее, что откуда растет
Ну хотя бы слово про Kakao, пожалуйста
Спасибо за статью, однако мне очень обидно и сейчас я обьясню почему ;)
Начнем с того, что Kaspresso со всеми PageObjectами опирается не на Espresso а на Kakao, который предоставляет DSL для Espresso, которое под капотом как раз выполняет описанные вами вроде
В дополнение к Kakao, Kaspresso как раз предоставляет дополнительный функционал вокруг adb и прочих ништячков
Ах как жаль, что в такой замечательной статье нет ни одного упоминания про Kakao.
С наилучшими пожеланиями, Vacxe, который немножко разбирается в кодовой базе Kakao, Kaspresso и Marathon =)
К сожалению, это ошибочное заблуждение.
Любое разбиение на слои так или иначе добавляет рутинный (boilerplate) код. Крайне часто интеракторы в данной концепции являются прокси между репозиторием и вью уровнями, тогда почему мы их не убирает для «сокращения кода»?
RxJava же по своей сущности является инструментом для планирования бизнес логики, а как следствие должна находиться на уровнях Repository & Interactor Implementation. Interactor Interface должен возвращать интерфейс который отвечает за возврат данных. А возвращая Observable в данной концепции вы теряете логику отвественности в слоях плюс использование Flowable Completable and etc. В чем главная проблема — если вы решите переехать на coroutines предположим, то Presentation layer тоже будет задет. С разделением через интерфейсы — вам будет необходимо изменить реализацию Interaction Impl. И вы сможете плавно выполнить миграцию.
Если вы хотите развлечения, то на уровне бизнес логики вам необходимы атомарные сущности интеракторов (чтение — запись в базу, запросы из веб апи и тд) каждый из которых может быть протестирован независимо, и композиционные сущности которые будут обьединять атомарные в бизнес логику. Да, данный подход будет еще более boilerplate но чистота кода (логическое разделение) обратно пропорциональна усложнению по сущностям.
В заключении — ваш подход весьма спорный и все зависит от обьема проекта, требований на тестирование и тд.
Накинуть ПР в марафон не хотите? Добавить флаг конфигурации с реализацией. Или форк ушел слегка дальше чем это изменение?
Какао пробовали?
Также релиз процессы зачастую поставлены на поток и происходят раз в неделю, форнайтли или месячно.
Ну и в заключение, не знание про «Badoo» как о компании очень разочаровывает. Ребята делают весьма не плохой вклад в развитие IT — сообщества в целом.
Проект от Triple-J с Gradle плагином по мне весьма сомнительное решение так как система сборки не должна знать о дистрибьюции.
Да, есть Java и JS библиотеки, но все они обернуты в какие то специфические кейсы, как например эта
Зачастую требуется единичная задача на CI которая отвечает исключительно за выгрузку APK и mapping (В нашем случае). Грубо говоря есть темплейт задачи в котором лежат все необходимые пароли на прокси и так далее и при создании TCE Build просто переопределяются названия файлов и куда заливать.
На выходных обернули Google Play API (Java) в прозрачный CLI
В ближайшее время сделаем аналог для npm так как есть проблемы с apline
Ну и в заключении, тулинг выбирается под задачу. Спасибо за статью!
Спасибо за статью. Если работаешь автоматизацией тестирования будешь страдать априори. Я конечно понимаю, что уже у вас стабильная система и переписывать ее не имеет смысла исходя из ресурсозатрат но стоит взглянуть на STF (Resources manager) + Marathon (Test orchestrator). Ещё можно сделать автоматический скейл агентов. Предположим у вас капасити на 50 агентов с эмуляторами но если они не используются в течение часа то убиваются. Это позволит очень сильно облегчит ресурсы в ночное время.
Спасибо за статью Жень. Всей команде спасибо огромное. Очень здорово что выкатили импакт анализ. Давно его пиарили, посмотрим на сколько он хорош.
С нетерпением жду следующий статьи и объяснения, чем же вас не устроил чистый Marathon ;)
Я обожаю спрашивать самые простые задачи, но они должны быть показательными.
Пример: «Посчитать уникальное количество символов в строке. „AABB“ = 2, „ABBA“ = 2, „AAAA“ = 1»
Почему задача показательная? Потому что ее можно решить множеством способов, но чистых будет мало. Большинство (да да 80%), решают данную задачу через «Map» и это странно. Ну да ладно.
Не надо сразу давать вопросы уровня Nightmare. Очень приятно поговорить про базовый уровень, типа сложность коллекций и так далее.
Вам необходимо нащупать тот уровень, где кандидат начинает плавать в вопросах.
Почему это хорошо? Допустим у вас стоит задача найти Senior, а кандидат идет как Intermediate. Возможно в вашей компании есть открытая позиция. Да и зачастую выгоднее взять смышленого Inter`а чем зазнавшегося Senior`a
Ах да, по возможности давайте отзыв о кандидате ему лично. За последние 5 минут, сказать где у него были недочеты и что ему нужно улучшить. «Извини дорогой Джонни, в нашем проекте необходимы знания в А Б В — фреймворках, а ты плохо в них разбираешься. Давай ка ты почитаешь книги от А.Я. Клешня И.Я Клешня, и попробуешь через полгода» — таким образом человек будет знать, в каких областях ему нужно улучшить знания.
Когда я только поступал к институт на САПР, мои школьные друзья уже начинали работать. Да, это была достаточно примитивная работа — продавец консультант, мерчендайзер и т.д. И знаете что, тогда я реально завидовал им. Я думал, что вот они получают 50к рублей и это круто, а у меня стипендия в 5к и стратегический запас дошираков.
Прошло какое то время, у меня появились базовые знания к компьютерных науках (где-то три года, чтобы не забивать на учебу), и я вышел на первую работу. Как сейчас помню, я был крайне рад этим 25к в месяц! Мне давали кодить реальный продукт, я учился у настоящих программистов.
Спустя еще какое то время, я сменил работу уже в направление, которое мне было интересно, и я стал получать 60к в месяц! Но прошло уже 5 лет обучения и опыта. А мои друзья все продолжали делать тоже самое за те же самые деньги. Примерно тогда я понял, что труды окупились.
Прошло еще 5 лет, и я уже два раза успел сменить страну проживания. Если я захочу переехать практически в любой город мира — найти друзей не проблема. Везде сделают референсы, так как огромная сеть коллег. А друзья до сих пор работают продавцами-консультантами.
Стать программистом — достаточно легко в наше время. Быть программистом — скорее призвание. Нельзя без любви к профессии добиться реальных высот. Да и зарплата не является основным мотивирующим фактором.
— Сравнение с водителем автобуса весьма не уместно. В стране где я живу, зарплата водителя автобуса составляет 80к в год, что эквивалентно зарплате мидл программиста. Но проезд на автобусе стоит около 4 долларов. Пересчитаем в эквивалент на рубли (1 доллар вместо 4) — приблизительно 60-70 тысяч в месяц (в Москве), что соответсвует реалиям. Так устроен рынок.
Да. Еще есть вариант пойти работать «держать Lollipop». Это что-то вроде дорожного знака (Stop\Slow) приблизительно за 60к долларов в год. Джуну будут платить примерно также.
Для этого было потрачено
1) Страховка — порядка 70 баксов (30 минут)
2) Регистрация как телекомуникационного устройства — бесплатно (45 минут)
3) Регистрация в СААТ — бесплатно (около трех месяцев!)
Могу описать процесс подробно, если необходимо.