То, что вам следует тестировать, зависит от таких факторов, как тип приложения, команда разработчиков, объем устаревшего кода и используемая архитектура. В следующих разделах описывается, что новичку следует учитывать при планировании тестирования в своем приложении.
Организация тестовых каталогов
Типичный проект в Android Studio содержит два каталога, в которых хранятся тесты в зависимости от среды их выполнения. Организуйте свои тесты в следующих каталогах, как описано:
- Каталог
androidTestдолжен содержать тесты, запускаемые на реальных или виртуальных устройствах. К таким тестам относятся интеграционные тесты, сквозные тесты и другие тесты, в которых JVM сама по себе не может проверить функциональность вашего приложения. - Каталог
testдолжен содержать тесты, которые выполняются на вашем локальном компьютере, например модульные тесты. В отличие от вышеперечисленного, это могут быть тесты, выполняемые на локальной JVM.
Основные модульные тесты
Следуя рекомендациям, вы должны убедиться, что используете модульные тесты в следующих случаях:
- Модульные тесты для ViewModels или презентаторов.
- Модульные тесты для уровня данных , особенно для репозиториев. Большая часть уровня данных должна быть независимой от платформы. Это позволит двойникам тестов заменять в тестах модули базы данных и удаленные источники данных. См. руководство по использованию тестовых двойников в Android.
- Модульные тесты для других независимых от платформы уровней, таких как уровень домена , а также для вариантов использования и интеракторов.
- Модульные тесты для служебных классов, таких как манипуляции со строками и математика.
Тестирование крайних случаев
Модульные тесты должны быть сосредоточены как на нормальных, так и на крайних случаях. Пограничные случаи — это необычные сценарии, которые вряд ли смогут обнаружить тестировщики-люди и более крупные тесты. Примеры включают следующее:
- Математические операции с использованием отрицательных чисел, нуля и граничных условий .
- Все возможные ошибки сетевого подключения.
- Поврежденные данные, например неверный формат JSON.
- Имитация полного хранилища при сохранении в файл.
- Объект, воссозданный в середине процесса (например, действия при вращении устройства).
Юнит-тесты, которых следует избегать
Некоторых модульных тестов следует избегать из-за их низкой ценности:
- Тесты, которые проверяют корректность работы фреймворка или библиотеки, а не вашего кода.
- Точки входа в структуру, такие как действия, фрагменты или службы, не должны иметь бизнес-логики, поэтому модульное тестирование не должно быть приоритетом. Модульные тесты для действий не имеют особой ценности, поскольку они охватывают в основном код платформы и требуют более сложной настройки. Эти классы могут охватывать инструментальные тесты, такие как тесты пользовательского интерфейса.
UI-тесты
Существует несколько типов UI-тестов, которые вам следует использовать:
- Тесты пользовательского интерфейса экрана проверяют важные взаимодействия пользователя на одном экране. Они выполняют такие действия, как нажатие кнопок, ввод форм и проверка видимых состояний. Один тестовый класс на экран — хорошая отправная точка.
- Тесты потока пользователей или тесты навигации , охватывающие наиболее распространенные пути. Эти тесты имитируют перемещение пользователя по потоку навигации. Это простые тесты, полезные для проверки сбоев во время инициализации.
Другие тесты
Существуют более специализированные тесты, такие как тесты скриншотов, тесты производительности и тесты на обезьянах . Вы также можете классифицировать тесты по назначению, например регрессии, доступности и совместимости.
Дальнейшее чтение
Чтобы провести изолированное тестирование, вам часто необходимо заменить зависимости тестируемого объекта фальшивыми или ложными зависимостями, которые обычно называются «тестовыми двойниками». Продолжить чтение о них можно в разделе «Использование тестовых двойников в Android» .
Если вы хотите узнать, как создавать модульные и UI-тесты, ознакомьтесь с разделами «Тестирование кода» .