Автотесты на Android. Картина целиком

у нас в данный момент стоит соотношение 1cpu(логическое ядро) ~ 3.5gb ram на эмулятор (в k8s)

Автотесты на Android. Картина целиком

github.com/google/android-emulator-container-scripts#requirements
пункт про kvm самый важный

Прямой эфир: СI/CD в iOS и Android

На все вопросы из комментариев постараемся ответить во время прямого эфира

Ask me anything. Avito. Android

1. Все занимаются. У меня нет под рукой статистики, но очень грубо треть всех автотестов под андроид написали функциональные тестеровщики, треть андроид разработчики, треть QA-dev, видел немного тестов от бекендеров и фронтендеров (изучали видимо как у нас оно устроено). Есть еще порядка шестисот компонентных UI тестов(больше изоляции чем у end-to-end), они почти все написаны разработчиками

2. У нас для этого отдельная команда, вот мы как раз с nnesterov оттуда. На нас релиз продукта и инфрастуктура вокруг этого.

3. Да, автоматизация тестрования есть почти во всех проектах. У каждой команды свой набор сценариев, хотя iOS и Android очевидно сильно пересекаются. Мы наоборот ушли от унификации всего автотестирования к решениям которые затачиваются под платформу.

4. Все возможные тесты запускаются на каждый пуш в рамках PullRequest. Работаем над оптимизацией при помощи Impact анализа на основе диффов: это уже работает в юнит тестах, в ближайшее время сделаем для UI

5. Все запускается автоматом, периодически появляются issue на ручной запуск, но я старательно резолвлю их с Won't Fix :), т.к. считаю что это плохая практика

Ask me anything. Avito. Android

Мы форкнулись еще до появления отчетов, и сразу пошли путем «решаем свои текущие задачи». Сейчас это вряд ли уже можно хоть как-то замерджить обратно.
Если мы в конце концов выложим форк к себе на github, можно будет обсудить предметно что делать со всем этим, возможно я преувеличиваю проблемы

Я не говорил что апдейт имаджей не проблема :) Однако если с образом все хорошо собралось, то нестабильности в дальнейшем не наблюдаем.
В подкаст зовите, с удовольствием поучаствую

Ask me anything. Avito. Android

У нас своя обертка (набор костылей), вокруг espresso + uiautomator2 одновременно. Я надеюсь что в феврале доберусь и опубликую ее на github.com/avito-tech.
Для запуска тестов мы используем внутренний форк github.com/gojuno/composer, правда переписанный уже до неузнаваемости. Там например реализован динамический шардинг и запуск всех тестов в отдельных instumentation процессах. Тоже подумаем над публикацией.

Ask me anything. Avito. Android

1. Эмуляторы достаточно стабильны уже! Удивительно сколько работы проделал google за последнее время в этом направлении.
   Чтобы избавиться от потенциальных проблем мы запускаем эмуляторы перед самим тестированием и роняем контейнеры после. Никакого специального тулинга для стабилизации здесь не требуется на данный момент. У нас есть программа на питоне, которая принимает yaml конфиг и стартует особым образом эмуляторы.
   конфиг выглядит например вот так:

   
   

   configuration:
   network: CI
   image: <local-registry>/android-emulator:<tag>
   environments:
   default:
     - 'animations_disabled'
     - 'spell_checker_disabled'
     - 'ime_hard_keyboard'
   
   functional-19:
       api: 19
       replicas: 10
   
   functional-22:
       api: 22
       replicas: 10
   
   functional-23:
       api: 23
       replicas: 10
   
   functional-24:
       api: 24
       replicas: 10

   
   

2. в 2017ом мы в основном тестировали на FirebaseTestLab, но на наших масштабах это дорого, долго (очереди на популярные девайсы), нестабильно (черный ящик и непонятные сроки решения проблем). В конце года мы полностью переехали на свои мощности. Тестируем только на эмуляторах (см конфиг для регресса выше). API выбрали как 4 самые популярные у юзеров.

   
   
3. На всякий случай не буду ничего подробно расписывать (sensitive инфа как никак), скажу только что вся процедура происходит автоматически.

Ask me anything. Avito. Android

Набор сервисов у нас довольно типичный: JIRA/TeamCity/BitbucketServer

Как только происходит открытие PullRequest инициируется параллельная серия проверок (скриншот) и ревью кода. Как только все это окрасится в зеленый цвет — происходит мердж в ветку синхронизации (develop)



Все task'и на CI — это скрипты (bash / python), лежащие в репозитории с проектом.
Скрипты запускают команды в docker контейнерах. Эмуляторы для instrumentation-тестов также живут в контейнерах.

Выполняется все это в kubernetes кластере по соседству со всем остальным CI Avito.

Для того чтобы избежать проблем со сломанным кодом после мерджа мы предварительно подмердживаем первым шагом код из develop.
Если за время проверок кто-то успел смерджится — проверки стартуют заново.
Реализовано это при помощи самописного плагина для Bitbucket Server, он стартует билды в TeamCity, отменяет неактуальные, а также может автоматически замерджить твой PR при достижении нужных кондиций (если ты его об этом попросишь)

Встреча Android-разработчиков, посвящённая языку Kotlin

https://www.youtube.com/watch?v=8u4fZ1z4X-w
Но с ужасным звуком. простите :(

Встреча Android-разработчиков, посвящённая языку Kotlin

Изначально не планировали, хотелось именно “встретиться”, но если будут ещё заявки на трансляцию, то попробуем организовать! Запись докладов сделаем.

Доступна IntelliJ IDEA 15 Preview

а Kotlin?

I/O Schedule 2014: плохой пример для обучения

github.com/chrisbanes/philm неплохо написан. Мне не очень нравятся его god-контроллеры, но в целом разбор кода этого приложения неплохо помог понять некоторые архитектурные решения.

Реактивное программирование под Android

все работает. lambdas, rxjava, retrolambda, AS 0.8.1

вот тут есть работающий пример, из которого я брал конфиг
github.com/fs/android-base

Реактивное программирование под Android

github.com/evant/rxloader попробуйте это

Создание оффлайн карты для iOS приложения

так сколько в итоге приложение весит?
точнее интересуют именно тайлы

Android компонент с нуля

Хендлер и меседжи вместо runOnUiThread — велосипед, незнание основ.

public final void runOnUiThread(Runnable action) {
        if (Thread.currentThread() != mUiThread) {
            mHandler.post(action);
        } else {
            action.run();
        }
    }

на самом деле не все так страшно, в остальном жирный плюс

Android компонент с нуля

думаю будет лучше оставлять в тексте «activity» в таком случае

Android компонент с нуля

source.android.com/source/code-style.html — автору

Android компонент с нуля

Это совсем не исключает наличие кастомных компонентов, и уж точно не означает что девелоперы не должны уметь их писать.
Вы же против крайностей?

Технология CORE

Чем больше в интернете разных подходов описать одну и ту же проблему — тем проще новичкам будет учиться.
Задача опытных девелоперов тут — не допустить в статьях откровенных ошибок в решении проблемы.

и да, хорошо если в решении будут линки на хрестоматийную литературу

p.s. сори чет не прикрепилось куда надо, это ответ для maxatwork