Тестирование мобильных приложений

Давайте поговорим о том, как можно организовать процесс тестирования мобильных приложений. За свою практику я познакомился с разными подходами и вот какие плюсы и минусы я вижу:

1. Ручное тестирование
Самый распространённый вариант, когда в команде есть QA, и он тестирует новые фичи и проводит регрессию.
➕ Лучший способ находить самые непредсказуемые баги, о которых разработчик даже не мог подумать.
➖ Дорого: нужно содержать штат QA, покупать девайсы для тестирования. А если регресс занимает пару дней, получаем ещё и выгоревших сотрудников.

2. Автотесты на эмуляторах/симуляторах
Второй по популярности вариант, автоматизируем те же тест-кейсы, что и проходит тестировщик. Так мы можем быть почти уверены, что ничего не сломали.

➕ Позволяет автоматизировать регресс, UI-тесты проходят значительно быстрее ручного тестирования.
➖ Есть множество проблем с поддержкой UI-тестов, и далеко не всё можно проверить на эмуляторе/симуляторе.

3. Мобильная ферма
В этом случае мы используем ферму из реальных устройств, на ней можно проводить как ручное тестирование, так и запускать UI-тесты.

Такой подход используют, например, в Яндексе с более чем 800 устройствами. Я не представляю, сколько это стоит, ведь для каждого iPhone нужен отдельный MacBook ☠️
Из open source-решений есть STF и DeviceHub, у которых тоже есть свои плюсы и минусы.
Другой вариант — аренда фермы девайсов. Например, такие услуги предоставляет компания Selectel.

➕ Самое качественное тестирование: множество разных девайсов позволяет воспроизводить самые специфичные баги.
➖ Очень дорого создавать собственное решение. Позволить себе это могут только крупные компании, но можно воспользоваться арендой устройств, чтобы значительно сэкономить.

🔖 Если тема заинтересовала и хотите узнать подробнее, то есть хорошая статья по теме, рекомендую!

#Testing #MobileFarm

Вы знаете, я люблю острые ощущения, поэтому решил попробовать встроить Jetpack Compose экран в приложение на React Native.

Так вот, это была ошибка, я по дороге несколько раз умер 😵

Казалось бы, читаем документацию, как встроить AndroidView в RN, оборачиваем ComposeView во FrameLayout и готово, делов-то.

И всё хорошо, пока эта вьюшка отображается на первом экране, но из-за особенностей навигации в RN будем получать ошибку cannot locate windowRecomposer.

AI-агенты впадают в экзистенциальный кризис при попытке решить эту задачу и зависают в бесконечном цикле правок, поэтому я начал шерстить интернет в поисках решения и нашёл доклад от Купера.

Исходников, конечно, я не нашёл, поэтому скормил скриншоты из доклада ChatGPT, чтобы она восстановила код, и это даже заработало 🤯

🌐 Выкладываю gist для таких же искателей приключений, но полноценно я это ещё не протестировал, так что используйте аккуратно.

P.S. Слабонервным код лучше не смотреть

Разумеется, вы слышали о нашумевшем обновлении iOS с Liquid Glass: на картинках всё выглядит красиво, но как это будет выглядеть в вашем приложении, если все нативные компоненты разом поменяются? И как успеть всё исправить до релиза?

Мой коллега, Антон Долганов, написал классную статью о том, как мы готовимся к новым версиям iOS.

В статье, на примере подготовки к iOS 26, вы найдёте пошаговый процесс адаптации к обновлениям системы и узнаете, какие проблемы могут встретиться по пути.

🔖 Приятного чтения!

Двигаем списки оптимально

Представьте, что вам нужно реализовать drag&drop список, в котором можно менять элементы местами. Элементы списка хранятся в БД, и мы можем добавить туда поле priority, по которому будет выполняться сортировка.

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

Но представим, что у вас сотни таких элементов, и вы двигаете последнюю карточку в начало списка. Тогда придётся сделать 100 записей в БД — звучит не очень оптимально 🤔

Как сделать лучше?

Можно заполнять поле priority не с шагом 1, а, например, с шагом 100.

🟢Тогда при перестановке элемента в середину списка нам будет достаточно взять средний приоритет между соседними значениями и обновить только один элемент в БД.

🟢Для крайних элементов тоже всё просто: либо вычитаем шаг приоритета, либо прибавляем.

🟢Но может случиться так, что после многих перестановок разница между элементами станет равной 1, только тогда придётся перезаписать все приоритеты.

Итого: в первом варианте у нас всегда была бы сложность O(N), а во втором, в большинстве случаев O(1), и только в худшем сценарии мы получим линейное время.

❓ А вы бы стали заморачиваться с оптимизацией? Или сделали бы простой вариант?

Путеводитель по каналу

Спустя ровно год канал набрал ещё тысячу подписчиков, спасибо вам, что читаете 🦞

Собрал для вас самые интересные посты по темам, вдруг найдёте что-то полезное для себя:

Compose
Что такое Compose Snapshot
Анимации по стейту в Compose
Проблемы Compose for WEB
Декларативный Bottom Sheet
Управляем курсором в TextField
Compose в React Native
SwiftUI в Compose Multiplatform
Отличия в модификаторах в SwiftUI и Compose
Must-have материалы для изучения Compose

iOS и KMP
iOS библиотеки в Kotlin коде
Собираем iOS приложения без macOS
Ставим iOS приложение из браузера
Как подключить KMP в iOS проект без CocoaPods
Фоновая работа в Android и iOS
Отличия при работе с БД на Android и iOS
Разное поведение Map на платформах
Интероп suspend и async функций
Зачем использовать новый Uuid

Android
Бессмертное приложение
Как сделать плитку в быстрых настройках
Шарим библиотеки между проектами

Корутины
Корутинные рецепты
Статья про нестандартное использование корутин

Библиотеки
Detekt правила для Decompose
Как зашифровать SharedPreferences
Библиотека для декларативного показа Snackbar

Разное
Об авторе канала
Мое первое мобильное приложение
Автоматизации в умном доме
Как опубликовать приложение с VPN в Google Play

#Навигация