Оптимизируйте свои подборки
Сохраняйте и классифицируйте контент в соответствии со своими настройками.
То, что вам следует тестировать, зависит от таких факторов, как тип приложения, команда разработчиков, объем устаревшего кода и используемая архитектура. В следующих разделах описывается, что новичку следует учитывать при планировании тестирования в своем приложении.
Организация тестовых каталогов
Типичный проект в Android Studio содержит два каталога, в которых хранятся тесты в зависимости от среды их выполнения. Организуйте свои тесты в следующих каталогах, как описано:
Каталог androidTest должен содержать тесты, запускаемые на реальных или виртуальных устройствах. К таким тестам относятся интеграционные тесты, сквозные тесты и другие тесты, в которых JVM сама по себе не может проверить функциональность вашего приложения.
Каталог test должен содержать тесты, которые выполняются на вашем локальном компьютере, например модульные тесты. В отличие от вышеперечисленного, это могут быть тесты, выполняемые на локальной JVM.
Основные модульные тесты
Следуя рекомендациям, вы должны убедиться, что используете модульные тесты в следующих случаях:
Модульные тесты для ViewModels или презентаторов.
Модульные тесты для уровня данных , особенно для репозиториев. Большая часть уровня данных должна быть независимой от платформы. Это позволит двойникам тестов заменять в тестах модули базы данных и удаленные источники данных. См. руководство по использованию тестовых двойников в Android.
Модульные тесты для других независимых от платформы уровней, таких как уровень домена , а также для вариантов использования и интеракторов.
Модульные тесты для служебных классов, таких как манипуляции со строками и математика.
Тестирование крайних случаев
Модульные тесты должны быть сосредоточены как на нормальных, так и на крайних случаях. Пограничные случаи — это необычные сценарии, которые вряд ли смогут обнаружить тестировщики-люди и более крупные тесты. Примеры включают следующее:
Математические операции с использованием отрицательных чисел, нуля и граничных условий .
Все возможные ошибки сетевого подключения.
Поврежденные данные, например неверный формат JSON.
Имитация полного хранилища при сохранении в файл.
Объект, воссозданный в середине процесса (например, действия при вращении устройства).
Юнит-тесты, которых следует избегать
Некоторых модульных тестов следует избегать из-за их низкой ценности:
Тесты, которые проверяют корректность работы фреймворка или библиотеки, а не вашего кода.
Точки входа в структуру, такие как действия, фрагменты или службы, не должны иметь бизнес-логики, поэтому модульное тестирование не должно быть приоритетом. Модульные тесты для действий не имеют особой ценности, поскольку они охватывают в основном код платформы и требуют более сложной настройки. Эти классы могут охватывать инструментальные тесты, такие как тесты пользовательского интерфейса.
UI-тесты
Существует несколько типов UI-тестов, которые вам следует использовать:
Тесты пользовательского интерфейса экрана проверяют важные взаимодействия пользователя на одном экране. Они выполняют такие действия, как нажатие кнопок, ввод форм и проверка видимых состояний. Один тестовый класс на экран — хорошая отправная точка.
Тесты потока пользователей или тесты навигации , охватывающие наиболее распространенные пути. Эти тесты имитируют перемещение пользователя по потоку навигации. Это простые тесты, полезные для проверки сбоев во время инициализации.
Другие тесты
Существуют более специализированные тесты, такие как тесты скриншотов, тесты производительности и тесты на обезьянах . Вы также можете классифицировать тесты по назначению, например регрессии, доступности и совместимости.
Дальнейшее чтение
Чтобы провести изолированное тестирование, вам часто необходимо заменить зависимости тестируемого объекта фальшивыми или ложными зависимостями, которые обычно называются «тестовыми двойниками». Продолжить чтение о них можно в разделе «Использование тестовых двойников в Android» .
Контент и образцы кода на этой странице предоставлены по лицензиям. Java и OpenJDK – это зарегистрированные товарные знаки корпорации Oracle и ее аффилированных лиц.
Последнее обновление: 2025-07-29 UTC.
[[["Прост для понимания","easyToUnderstand","thumb-up"],["Помог мне решить мою проблему","solvedMyProblem","thumb-up"],["Другое","otherUp","thumb-up"]],[["Отсутствует нужная мне информация","missingTheInformationINeed","thumb-down"],["Слишком сложен/слишком много шагов","tooComplicatedTooManySteps","thumb-down"],["Устарел","outOfDate","thumb-down"],["Проблема с переводом текста","translationIssue","thumb-down"],["Проблемы образцов/кода","samplesCodeIssue","thumb-down"],["Другое","otherDown","thumb-down"]],["Последнее обновление: 2025-07-29 UTC."],[],[],null,["# What to test in Android\n\nWhat you should test depends on factors such as the type of app, the development\nteam, the amount of legacy code, and the architecture used. The following\nsections outline what a beginner might want to consider when planning what to\ntest in their app.\n\nOrganization of test directories\n--------------------------------\n\nA typical project in Android Studio contains two directories that hold tests\ndepending on their execution environment. Organize your tests in the following\ndirectories as described:\n\n- The `androidTest` directory should contain the tests that run on real or virtual devices. Such tests include integration tests, end-to-end tests, and other tests where the JVM alone cannot validate your app's functionality.\n- The `test`directory should contain the tests that run on your local machine, such as unit tests. In contrast to the above, these can be tests that run on a local JVM.\n\nEssential unit tests\n--------------------\n\nWhen following best practice, you should ensure you use unit tests in the\nfollowing cases:\n\n- **Unit tests** for **ViewModels**, or presenters.\n- **Unit tests** for the **data** layer, especially repositories. Most of the data layer should be platform-independent. Doing so enables test doubles to replace database modules and remote data sources in tests. See the guide on [using test doubles in Android](/training/testing/fundamentals/test-doubles)\n- **Unit tests** for other platform-independent layers such as the **Domain** layer, as with use cases and interactors.\n- **Unit tests** for **utility classes** such as string manipulation and math.\n\n### Testing Edge Cases\n\nUnit tests should focus on both normal and edge cases. Edge cases are uncommon\nscenarios that human testers and larger tests are unlikely to catch. Examples\ninclude the following:\n\n- Math operations using negative numbers, zero, and [boundary\n conditions](https://en.wikipedia.org/wiki/Off-by-one_error).\n- All the possible network connection errors.\n- Corrupted data, such as malformed JSON.\n- Simulating full storage when saving to a file.\n- Object recreated in the middle of a process (such as an activity when the device is rotated).\n\n### Unit Tests to Avoid\n\nSome unit tests should be avoided because of their low value:\n\n- Tests that verify the correct operation of the framework or a library, not your code.\n- Framework entry points such as *activities, fragments, or services* should not have business logic so unit testing shouldn't be a priority. Unit tests for activities have little value, because they would cover mostly framework code and they require a more involved setup. Instrumented tests such as UI tests can cover these classes.\n\nUI tests\n--------\n\nThere are several types of UI tests you should employ:\n\n- **Screen UI tests** check critical user interactions in a single screen. They perform actions such as clicking on buttons, typing in forms, and checking visible states. One test class per screen is a good starting point.\n- **User flow tests** or **Navigation tests**, covering most common paths. These tests simulate a user moving through a navigation flow. They are simple tests, useful for checking for run-time crashes in initialization.\n\n| **Note:** Test coverage is a metric that some testing tools can calculate, and indicates how much of your code is visited by your tests. It can detect untested portions of the codebase, but it should not be used as the only metric to claim a good testing strategy.\n\nOther tests\n-----------\n\nThere are more specialized tests such as screenshot tests, performance tests,\nand [monkey tests](/studio/test/monkey). You can also categorize tests by purpose, such as\nregressions, accessibility, and compatibility.\n\nFurther reading\n---------------\n\nIn order to test in isolation, you oftentimes need to replace the dependencies\nof the subject under test with fake or mock dependencies, called \"Test doubles\"\nin general. Continue reading about them in [Using test doubles in Android](/training/testing/fundamentals/test-doubles).\n\nIf you want to learn how to create unit and UI tests, check out the [Testing\ncodelabs](/codelabs/advanced-android-kotlin-training-testing-basics)."]]
