Стратегия тестирования приложения
Вопрос
Какую стратегию тестирования ты бы предложил для Android-приложения команды из пяти человек?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Пирамида: упор на юнит-тесты логики
Архитектура для тестируемости: DI, интерфейсы, stateless-экраны
Интеграционные: Room в памяти, MockWebServer, миграции
UI-тесты Compose на ключевые экраны, скриншотные для дизайна
Немного сквозных сценариев на устройстве
Запуск в CI на каждый PR, нестабильные тесты чинить сразу
Что могут спросить следом
- Как бороться с нестабильными UI-тестами?
- Какое покрытие считаешь достаточным?
Разбор
Опираюсь на пирамиду. Основа это юнит-тесты логики: ViewModel, use case, мапперы, репозитории с фейками. Они быстрые и запускаются на каждый коммит. Чтобы их было легко писать, архитектура должна это позволять: зависимости через конструктор, интерфейсы на границах, внедряемые диспетчеры, экраны, которые принимают UiState и колбэки. Второй слой интеграционные тесты: DAO на базе в памяти, проверка миграций по схемам, сетевой слой на MockWebServer. Третий слой UI: тесты Compose на ключевые экраны, они легко пишутся для stateless-экранов, и скриншотные тесты, чтобы ловить визуальные регрессии без устройства. На вершине несколько сквозных сценариев на эмуляторе: вход, покупка, главная лента. Всё запускается в CI на каждый PR, а нестабильный тест чиним или временно отключаем с задачей, иначе команда перестаёт доверять тестам. Покрытие смотрю как сигнал, а не цель.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.