Code coverage для UI тестов
⚙️ Тема анализа покрытия кода Unit тестами уже не нова, для Java уже давным-давно существует библиотека JaCoCo, для Kotlin есть официальный Gradle Plugin Kover. Оба этих инструмента позволяют анализировать ваш код и генерировать различные отчеты о его покрытии Unit тестами. Это безусловно полезные инструменты для улучшения качества вашего кода и уверенности в нем.
⚙️ Но как обстоят дела с UI тестами? Можем ли мы с помощью них проанализировать процент покрытия тестами нашей бизнес логики?
⚙️ На этот вопрос ответил мой коллега из Контура, Игорь Гордеев, в своей статье на Хабре. Он рассказал, как с помощью библиотеки VisualFSM, конечных автоматов и щепотки кодогенерации сделать такое покрытие и упростить жизнь и тестировщикам, и разработчикам в тысячу раз!
Приятного чтения🤯
#Android #Testing
Приятного чтения
#Android #Testing
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11👍3
Скриншот-тестирование
Практика скриншот-тестирования в Android началась еще более 10 лет назад и актуальна по сей день, за это время появилось огромное количество разных библиотек (Paparazzi, Shot, Testify и другие), но у всех библиотек есть существенный недостаток — поддержка. Всегда есть риски, что библиотеку перестанут поддерживать или будут обновлять зависимости несвоевременно.
И ребята из Тинькофф для тестирования дизайн-системы пошли другим путем, не используя сторонние библиотеки, так как все, что нужно для скриншот-тестирования уже есть в Android! (на самом деле нет)
Достаточно взять эталонный и текущий скриншот, сконвертировать все в Bitmap и попарно сравнить пиксели:
Но разумеется это только верхушка айсберга и, чтобы построить хороший процесс тестирования дизайн-системы, нужно решить еще множество проблем.
И вот список рекомендаций из их доклада про что нужно помнить:
▫️ Подготовьте storybook и используете эти же состояния компонентов для тестирования
▫️ Сделайте удобный тулинг для обновления эталонных скриншотов и просмотра диффа скриншотов
▫️ Используйте CI как единый источник правды для создания эталонных скриншотов, так как на разных процессорах графика может отличаться
▫️ Избавляйтесь от запуска тестов на эмуляторе, в этом может Robolectric с режимом
▫️ Подумайте о генерации тестов через KSP
Но, что если ваш проект полностью написан на Jetpack Compose? Неужели нет других вариантов скриншот-тестирования? Об этом расскажу в следующем посте, так что stay tuned!
#Testing #SnapshotTesting #Android
Практика скриншот-тестирования в Android началась еще более 10 лет назад и актуальна по сей день, за это время появилось огромное количество разных библиотек (Paparazzi, Shot, Testify и другие), но у всех библиотек есть существенный недостаток — поддержка. Всегда есть риски, что библиотеку перестанут поддерживать или будут обновлять зависимости несвоевременно.
И ребята из Тинькофф для тестирования дизайн-системы пошли другим путем, не используя сторонние библиотеки, так как все, что нужно для скриншот-тестирования уже есть в Android! (на самом деле нет)
Достаточно взять эталонный и текущий скриншот, сконвертировать все в Bitmap и попарно сравнить пиксели:
val referenceBitmap = BitmapFactory.decodeFile("assets/1.jpg")
val actualBitmap = onView(withId(R.id.mainContent)).captureToBitmap()
val isSameImage = compareBitmaps(referenceBitmap, actualBitmap)
assertTrue(isSameImage)
Но разумеется это только верхушка айсберга и, чтобы построить хороший процесс тестирования дизайн-системы, нужно решить еще множество проблем.
И вот список рекомендаций из их доклада про что нужно помнить:
@GraphicsMode(NATIVE)
Но, что если ваш проект полностью написан на Jetpack Compose? Неужели нет других вариантов скриншот-тестирования? Об этом расскажу в следующем посте, так что stay tuned!
#Testing #SnapshotTesting #Android
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15👍2❤1
Тестирование мобильных приложений
Давайте поговорим о том, как можно организовать процесс тестирования мобильных приложений. За свою практику я познакомился с разными подходами и вот какие плюсы и минусы я вижу:
1. Ручное тестирование
Самый распространённый вариант, когда в команде есть QA, и он тестирует новые фичи и проводит регрессию.
➕ Лучший способ находить самые непредсказуемые баги, о которых разработчик даже не мог подумать.
➖ Дорого: нужно содержать штат QA, покупать девайсы для тестирования. А если регресс занимает пару дней, получаем ещё и выгоревших сотрудников.
2. Автотесты на эмуляторах/симуляторах
Второй по популярности вариант, автоматизируем те же тест-кейсы, что и проходит тестировщик. Так мы можем быть почти уверены, что ничего не сломали.
➕ Позволяет автоматизировать регресс, UI-тесты проходят значительно быстрее ручного тестирования.
➖ Есть множество проблем с поддержкой UI-тестов, и далеко не всё можно проверить на эмуляторе/симуляторе.
3. Мобильная ферма
В этом случае мы используем ферму из реальных устройств, на ней можно проводить как ручное тестирование, так и запускать UI-тесты.
Такой подход используют, например, в Яндексе с более чем 800 устройствами. Я не представляю, сколько это стоит, ведь для каждого iPhone нужен отдельный MacBook ☠️
Из open source-решений есть STF и DeviceHub, у которых тоже есть свои плюсы и минусы.
Другой вариант — аренда фермы девайсов. Например, такие услуги предоставляет компания Selectel.
➕ Самое качественное тестирование: множество разных девайсов позволяет воспроизводить самые специфичные баги.
➖ Очень дорого создавать собственное решение. Позволить себе это могут только крупные компании, но можно воспользоваться арендой устройств, чтобы значительно сэкономить.
🔖 Если тема заинтересовала и хотите узнать подробнее, то есть хорошая статья по теме, рекомендую!
#Testing #MobileFarm
Давайте поговорим о том, как можно организовать процесс тестирования мобильных приложений. За свою практику я познакомился с разными подходами и вот какие плюсы и минусы я вижу:
1. Ручное тестирование
Самый распространённый вариант, когда в команде есть QA, и он тестирует новые фичи и проводит регрессию.
2. Автотесты на эмуляторах/симуляторах
Второй по популярности вариант, автоматизируем те же тест-кейсы, что и проходит тестировщик. Так мы можем быть почти уверены, что ничего не сломали.
3. Мобильная ферма
В этом случае мы используем ферму из реальных устройств, на ней можно проводить как ручное тестирование, так и запускать UI-тесты.
Такой подход используют, например, в Яндексе с более чем 800 устройствами. Я не представляю, сколько это стоит, ведь для каждого iPhone нужен отдельный MacBook ☠️
Из open source-решений есть STF и DeviceHub, у которых тоже есть свои плюсы и минусы.
Другой вариант — аренда фермы девайсов. Например, такие услуги предоставляет компания Selectel.
#Testing #MobileFarm
Please open Telegram to view this post
VIEW IN TELEGRAM
👨💻16