Можно сказать, что у нас используется два импакт-анализа:
Во время регрессионного тестирования мы собираем список всех jira-задач и измененных файлов (git diff), которые выкатываются в этом релизе. Этот отчет мы передаем функциональным тестировщикам. Они, если хотят, вручную анализируют этот отчет и по нему подбирают набор тест-кейсов, которые надо проверить.
На каждом pull request мы автоматически собираем список измененных файлов (опять таки git diff) и по этому списку строим набор тестов, которые нужно запустить на pull request'е. Тесты, которые не могут быть затронуты изменениями, мы не запускаем. Это делаем для ускорения билдов. Подробности реализации можно посмотреть в докладе Димы Меркурьева: https://youtu.be/EBO2S9qcp0s?t=6946
Пока с девайсами работаем так: взял — запишись в электронную табличку. Чтобы не вписываться руками, в рамках хакатона разработали концепт системы записи по пропускам: https://habrahabr.ru/company/avito/blog/342466/ (см. “Учёт мобильных девайсов“).
В комменте выше отвечали на подобный вопрос. Для автоматизированного тестирования используем эмуляторы, запускаем и останавливаем их с помощью Docker. QA-специалисты для ручного тестирования используют целый зоопарк реальных устройств, разных производителей и разных версий.
В этом комменте рассказывается о нашей системе CI/CD.
На этот вопрос не могу ответить, к сожалению. Отдел security меня за это отругает :)
NDK в приложении не используется. Подходящих задач нету.
В целом, у нас нет ни чистого ООП, ни чистого ФП. Весь код пишется на классах и объектах, но с сильным креном в сторону чистых функций, иммутабельных объектов и прочего.
Привет. Сейчас в нашем проекте около 10 тысяч junit-тестов и чуть больше тысячи instrumentation-тестов.
С флаки instrumentation-тестами боремся перезапуском тестов. Либо на стороне composer, либо с помощью Rule.
Здравствуйте.
Все отзывы, вопросы и предложения внимательно анализируют продакт менеджеры. Они собирают статистику по проблемам и желаемым фичам, создают тикеты и распределяют их по соответствующим командам в зависимости от типов задач.
Например, в случаях, если пользователи пишут о неизвестном нам баге, то служба поддержки заводит тикет на QA специалистов ответственной команды. Кроме того, для разработчиков у нас настроен канал с отзывами из магазинов приложений в Slack, в который дублируются вообще все вопросы. Важно, чтобы команда видела не только информацию по своим функциональным задачам, но и картину в целом.
Универсального решения по поводу количества Activity и Fragment нет. Все зависит от специфики приложений и желания разработчиков. Кому-то больше по душе использовать только Activity, кому-то очень нравится подход Single Activity Application. Наша команда находится где-то посередине. Логически связанные куски оформляются в виде отдельной Activity с несколькими фрагментами. Пример: флоу подачи объявления.
Тест-кейсы пишутся в процессе разработки на основании бизнес-требований или документации. Далее при получении фичи тестировщик проводит функциональное тестирование и некоторые виды нефункционального. Например, тестирование установки. тестирование на отказ и восстановление. В некоторых командах сразу же пишутся автотесты. И потом уже на перед релизом проводится регрессионое тестирование.
К сожалению, пока никак. В целом мы стремимся к максимально тонкому клиенту и переносим максимум бизнес-логики на сторону сервера. То немногое, что остается на клиенте приходится писать два раза: для Android и для iOS. Очень внимательно следим за проектом Kotlin Native для шаринга кода между платформами.
Отдельного отдела QA у нас нет, функциональные тестировщики являются членами продуктовых команд. Тестирование можно разбить на два этапа: приемочное тестирование сразу после разработки фичи и регрессионное, проводящееся перед каждым релизом. Во время разработки фичи тестировщики пишут тест-кейсы для них и, по желанию, авто-тест для проверки. Непротестированные фичи либо живут в своих ветках, либо изолированы фиче-тогглом. После прохождения ручного или автоматического приемочного тестирования фича включается в следующий релиз, а тест-кейсы связанные с ней, — в регрессионный пакет. (edited)
Очень надеемся, что такой день не наступит никогда :) Наше приложение достаточно большое.
Стараемся поддерживать архитектуру частыми рефакторингами, испытанием новых подходов, частыми обсуждениями. Также помогают дотошное Code Review и периодические ретроспективы.
Мы стремимся в backend-driven UI, и абсолютное большинство текстов в приложении нам присылает сервер. На руку здесь нам играет то, что наше приложение поддерживает только русский язык и не надо заморачиваться с локализацией.
А нет ли здесь нарушения SRP? Presenter получается таким god-object, который знает почти все о работе приложения. Получается, что тут целых три причины для изменения презентера:
Изменение способа отображения данных
Изменение слоя данных
Изменение логики переходов по экранам внутри приложения
Достаточно хрупкая и размытая абстракция, не находите?
Почему бы не инкапсулировать 2-й пункт в Interactor, 3-й — в Router? Получится, конечно же, больше классов. Но они маленькие, имеют строгую зону ответственности и проще тестируются.
У каждого программиста обычно свое понимание MVP. В вашем понимании MVP, кто общается со слоем данных? Presenter напрямую? А если нужно исходные данные немного преобразовать перед отображением? А кто отвечает за обработку переходов между экранами?
Извините, я не очень знаком с типичной архитектурой iOS-приложений. Поэтому часть вопросов может показаться глупой :)
>> Другими словами, тому кто уже на перекрестке должно быть насрать (кстати, тупить также как и ездить задним ходом на перекрестке запрещают ПДД :) ) на то, кто и кому должен уступать из тех кто к перекрестку только подъехал.
Не совсем так. Точнее, совсем не так
ИЗ ПДД:
13.9. На перекрестке неравнозначных дорог водитель транспортного средства, движущегося по второстепенной дороге, должен уступить дорогу транспортным средствам, приближающимся по главной, независимо от направления их дальнейшего движения.
…
«Уступить дорогу (не создавать помех)» — требование, означающее, что участник дорожного движения не должен начинать, возобновлять или продолжать движение, осуществлять какой-либо маневр, если это может вынудить других участников движения, имеющих по отношению к нему преимущество, изменить направление движения или скорость.
Таким образом, если ТС «А» выехало на перекресток, заставив притормозить ТС «Б», движущее по главное дороге, то ТС «А» при любых внешних обстоятельствах нарушило ПДД
А если (в случае с переворотом\пересозданием активити) фоновая операция закончится уже после того, как первая активити отвязалась, но до того, как вторая активити привязалась. Результат загрузки пропадет?
Спасибо за поправку. Не совсем верно написал. Наша JVM делает то, что должна (кеширует объекты для интервала -128..127), но не делает дополнительно то, что может делать (кешировать объекты вне этого интервала. ). Немного поправил статью
В своем проекте так и не заставил SQLite нормально воспринимать кириллицу без учета регистра. Решил проблему простым хаком: завел дополнительное поле в таблице для поиска. куда заносится информация только в нижнем регистре. Поиск требовался только по имени, поэтому это не сильно увеличило размер базы. Заказчик доволен :)
>> нельзя создать функцию/переменную/константу вне класса (ведь на любые действия или данные можно найти класс)
Да, но всех настолько достало постоянно писать Math.sin(), что в C# 6.0 ввели статические импорты.
Можно сказать, что у нас используется два импакт-анализа:
Во время регрессионного тестирования мы собираем список всех jira-задач и измененных файлов (
git diff), которые выкатываются в этом релизе. Этот отчет мы передаем функциональным тестировщикам. Они, если хотят, вручную анализируют этот отчет и по нему подбирают набор тест-кейсов, которые надо проверить.На каждом pull request мы автоматически собираем список измененных файлов (опять таки
git diff) и по этому списку строим набор тестов, которые нужно запустить на pull request'е. Тесты, которые не могут быть затронуты изменениями, мы не запускаем. Это делаем для ускорения билдов. Подробности реализации можно посмотреть в докладе Димы Меркурьева: https://youtu.be/EBO2S9qcp0s?t=6946Пока с девайсами работаем так: взял — запишись в электронную табличку. Чтобы не вписываться руками, в рамках хакатона разработали концепт системы записи по пропускам: https://habrahabr.ru/company/avito/blog/342466/ (см. “Учёт мобильных девайсов“).
Привет. Сейчас в нашем проекте около 10 тысяч junit-тестов и чуть больше тысячи instrumentation-тестов.
С флаки instrumentation-тестами боремся перезапуском тестов. Либо на стороне composer, либо с помощью Rule.
Здравствуйте.
Все отзывы, вопросы и предложения внимательно анализируют продакт менеджеры. Они собирают статистику по проблемам и желаемым фичам, создают тикеты и распределяют их по соответствующим командам в зависимости от типов задач.
Например, в случаях, если пользователи пишут о неизвестном нам баге, то служба поддержки заводит тикет на QA специалистов ответственной команды. Кроме того, для разработчиков у нас настроен канал с отзывами из магазинов приложений в Slack, в который дублируются вообще все вопросы. Важно, чтобы команда видела не только информацию по своим функциональным задачам, но и картину в целом.
Универсального решения по поводу количества Activity и Fragment нет. Все зависит от специфики приложений и желания разработчиков. Кому-то больше по душе использовать только Activity, кому-то очень нравится подход Single Activity Application. Наша команда находится где-то посередине. Логически связанные куски оформляются в виде отдельной Activity с несколькими фрагментами. Пример: флоу подачи объявления.
Мои коллеги немного поправили меня:
К сожалению, пока никак. В целом мы стремимся к максимально тонкому клиенту и переносим максимум бизнес-логики на сторону сервера. То немногое, что остается на клиенте приходится писать два раза: для Android и для iOS. Очень внимательно следим за проектом Kotlin Native для шаринга кода между платформами.
Отдельного отдела QA у нас нет, функциональные тестировщики являются членами продуктовых команд. Тестирование можно разбить на два этапа: приемочное тестирование сразу после разработки фичи и регрессионное, проводящееся перед каждым релизом. Во время разработки фичи тестировщики пишут тест-кейсы для них и, по желанию, авто-тест для проверки. Непротестированные фичи либо живут в своих ветках, либо изолированы фиче-тогглом. После прохождения ручного или автоматического приемочного тестирования фича включается в следующий релиз, а тест-кейсы связанные с ней, — в регрессионный пакет. (edited)
Очень надеемся, что такой день не наступит никогда :) Наше приложение достаточно большое.
Стараемся поддерживать архитектуру частыми рефакторингами, испытанием новых подходов, частыми обсуждениями. Также помогают дотошное Code Review и периодические ретроспективы.
По старым версиям:
Android 4.4 ~12%
Android 4.0-4.3 ~10%
Повышать minSdk (как бы этого ни хотелось :) ) пока не планируем, ориентируемся в этом вопросе на пользователей.
Мы стремимся в backend-driven UI, и абсолютное большинство текстов в приложении нам присылает сервер. На руку здесь нам играет то, что наше приложение поддерживает только русский язык и не надо заморачиваться с локализацией.
А нет ли здесь нарушения SRP? Presenter получается таким god-object, который знает почти все о работе приложения. Получается, что тут целых три причины для изменения презентера:
Достаточно хрупкая и размытая абстракция, не находите?
Почему бы не инкапсулировать 2-й пункт в Interactor, 3-й — в Router? Получится, конечно же, больше классов. Но они маленькие, имеют строгую зону ответственности и проще тестируются.
Извините, я не очень знаком с типичной архитектурой iOS-приложений. Поэтому часть вопросов может показаться глупой :)
Не совсем так. Точнее, совсем не так
ИЗ ПДД:
13.9. На перекрестке неравнозначных дорог водитель транспортного средства, движущегося по второстепенной дороге, должен уступить дорогу транспортным средствам, приближающимся по главной, независимо от направления их дальнейшего движения.
…
«Уступить дорогу (не создавать помех)» — требование, означающее, что участник дорожного движения не должен начинать, возобновлять или продолжать движение, осуществлять какой-либо маневр, если это может вынудить других участников движения, имеющих по отношению к нему преимущество, изменить направление движения или скорость.
Таким образом, если ТС «А» выехало на перекресток, заставив притормозить ТС «Б», движущее по главное дороге, то ТС «А» при любых внешних обстоятельствах нарушило ПДД
Да, но всех настолько достало постоянно писать Math.sin(), что в C# 6.0 ввели статические импорты.