Android test

Test Your App | Android Studio

Android Studio is designed to make testing simple. With just a few clicks, you can set up a JUnit test that runs on the local JVM or an instrumented test that runs on a device. Of course, you can also extend your test capabilities by integrating test frameworks such as Mockito to test Android API calls in your local unit tests, and Espresso or UI Automator to exercise user interaction in your instrumented tests. You can generate Espresso tests automatically using Espresso Test Recorder.

This page provides the basic information about how to add new tests to your app and run them from Android Studio.

For a more complete how-to guide for writing tests, see Testing Apps on Android.

Test types and location

The location of your test code depends on the type of test you are writing. Android Studio provides source code directories (source sets), for the following two types of tests:

Local unit tests

Located at module-name/src/test/java/.

These are tests that run on your machine's local Java Virtual Machine (JVM). Use these tests to minimize execution time when your tests have no Android framework dependencies or when you can mock the Android framework dependencies.

At runtime, these tests are executed against a modified version of android.jar where all final modifiers have been stripped off. This lets you use popular mocking libraries, like Mockito.

Instrumented tests

Located at module-name/src/androidTest/java/.

These are tests that run on a hardware device or emulator. These tests have access to Instrumentation APIs, give you access to information such as the Context of the app you are testing, and let you control the app under test from your test code. Use these tests when writing integration and functional UI tests to automate user interaction, or when your tests have Android dependencies that mock objects cannot satisfy.

Because instrumented tests are built into an APK (separate from your app APK), they must have their own AndroidManifest.xml file. However, Gradle automatically generates this file during the build so it is not visible in your project source set. You can add your own manifest file if necessary, such as to specify a different value for `minSdkVersion` or register run listeners just for your tests. When building your app, Gradle merges multiple manifest files into one manifest.

The Gradle build interprets these test source sets in the same manner as it does for your project's app source sets, which allows you to create tests based on build variants.

When you create a new project or add an app module, Android Studio creates the test source sets listed above and includes an example test file in each. You can see them in the Project window as shown in figure 1.

Figure 1. Your project's (1) instrumented tests and (2) local JVM tests are visible in either the Project view (left) or Android view (right).

Add a new test

To create either a local unit test or an instrumented test, you can create a new test for a specific class or method by following these steps:

  1. Open the Java file containing the code you want to test.
  2. Click the class or method you want to test, then press Ctrl+Shift+T (⇧⌘T).
  3. In the menu that appears, click Create New Test.
  4. In the Create Test dialog, edit any fields and select any methods to generate, and then click OK.
  5. In the Choose Destination Directory dialog, click the source set corresponding to the type of test you want to create: androidTest for an instrumented test or test for a local unit test. Then click OK.

Alternatively, you can create a generic Java file in the appropriate test source set as follows:

  1. In the Project window on the left, click the drop-down menu and select the Project view.
  2. Expand the appropriate module folder and the nested src folder. To add a local unit test, expand the test folder and the nested java folder; to add an instrumented test, expand the androidTest folder and the nested java folder.
  3. Right-click on the Java package directory and select New > Java Class.
  4. Name the file and then click OK.

Also be sure you specify the test library dependencies in your app module's build.gradle file:

dependencies { // Required for local unit tests (JUnit 4 framework) testCompile 'junit:junit:4.12' // Required for instrumented tests androidTestCompile '' androidTestCompile '' }

For other optional library dependencies and more information about how to write your tests, see Building Local Unit Tests and Building Instrumented Unit Tests.

Resolve conflicts between the app and test APK

Both your app APK and its test APK share the same classpath. So, you can get a build error if both APKs depend on different versions of the same library. If, for some reason, Gradle isn't able to detect this version conflict, your app may behave unexpectedly during runtime or crash.

To resolve this issue, simply make sure that you use the same version of each dependency that is common to both your app and its instrumented tests. To help you manage version numbers across your project, consider creating project-wide properties.

In some cases, version conflicts may occur from transitive dependencies (which are dependencies of the dependencies you configure in your build). To resolve this version conflict, explicitly declare the transitive dependency in the build script for your app or its instrumented tests, and use the higher available version number. To investigate transitive dependencies in your project, view the dependency tree.

Create instrumented test for a build variant

If your project includes build variants with unique source sets, then you might want corresponding instrumented test source sets. Creating instrumented tests in source sets that correspond to your build variants helps keep your test code organized and allows you to run only the tests that apply to a given build variant.

To add a testing source set for your build variant, follow these steps:

  1. In the Project window on the left, click the drop-down menu and select the Project view.
  2. Within the appropriate module folder, right-click the src folder and click New > Directory.
  3. For the directory name, enter "androidTestVariantName." For example, if you have a build variant called "MyFlavor" then the directory name should be "androidTestMyFlavor." Then click OK.
  4. Right-click on the new directory and click New > Directory.
  5. Enter "java" as the directory name, and then click OK.

Now you can add tests to this new source set by following the steps above to add a new test. When you reach the Choose Destination Directory dialog, select the new variant test source set.

The instrumented tests in src/androidTest/ source set are shared by all build variants. When building a test APK for the "MyFlavor" variant of your app, Gradle combines both the src/androidTest/ and src/androidTestMyFlavor/ source sets.

For example, the following table shows how instrumentation test files should reside in source sets that correspond to the app's code source sets.

Path to app class Path to matching instrumentation test class
src/main/java/ src/androidTest/java/
src/myFlavor/java/ src/androidTestMyFlavor/java/

Just as it does for your app source sets, the Gradle build merges and overrides files from different test source sets. In this case, the file in the "androidTestMyFlavor" source set overrides the version in the "androidTest" source set. For more information about how source sets are merged, see Configure Your Build.

Another reason you should use build variants for your app and test source sets is to create hermetic tests through mock dependencies. That is, you can create a product flavor for your app that contains fake implementations of dependencies (such as network requests or device sensor data that is ordinarily flaky), and then add a corresponding mock test source set. For more information, see the blog post about leveraging product flavors for hermetic testing.

Configure instrumentation manifest settings

When Gradle builds your test APK, it automatically generates the AndroidManifest.xml file and configures it with the <instrumentation> node. One of the reasons Gradle configures this node for you is to make sure that the targetPackage property specifies the correct package name of the app under test. You can change some of the other settings for this node by either creating another manifest file in the test source set or configuring your module-level build.gradle file, as shown in the following code sample.

android { ... // Each product flavor you configure can override properties in the // defaultConfig {} block. To learn more, go to Configure Product Flavors. defaultConfig { ... // Specifies the application ID for the test APK. testApplicationId "" // Specifies the fully-qualified class name of the test instrumentation runner. testInstrumentationRunner "android.test.InstrumentationTestRunner" // If set to 'true', enables the instrumentation class to start and stop profiling. // If set to false (default), profiling occurs the entire time the instrumentation // class is running. testHandleProfiling true // If set to 'true', indicates that the Android system should run the instrumentation // class as a functional test. The default value is 'false' testFunctionalTest true } } ...

Change the test build type

By default, all tests run against the debug build type. You can change this to another build type by using the testBuildType property in your module-level build.gradle file. For example, if you want to run your tests against your "staging" build type, edit the file as shown in the following snippet.

android { ... testBuildType "staging" }

Configure Gradle test options

The Android plugin for Gradle allows you to specify certain options for all or just some of your unit tests. In the module-level build.gradle file, use the testOptions {} block to specify options that change how Gradle runs all your tests.

android { ... // Encapsulates options for running tests. testOptions { // Changes the directory where Gradle saves test reports. By default, Gradle saves test reports // in the path_to_your_project/module_name/build/outputs/reports/ directory. // '$rootDir' sets the path relative to the root directory of the current project. reportDir "$rootDir/test-reports" // Changes the directory where Gradle saves test results. By default, Gradle saves test results // in the path_to_your_project/module_name/build/outputs/test-results/ directory. // '$rootDir' sets the path relative to the root directory of the current project. resultsDir "$rootDir/test-results" } }

To specify options for only local unit tests, configure the unitTests {} block inside testOptions {}.

android { ... testOptions { ... // Encapsulates options for local unit tests. unitTests { // By default, local unit tests throw an exception any time the code you are testing tries to access // Android platform APIs (unless you mock Android dependencies yourself or with a testing // framework like Mockito). However, you can enable the following property so that the test // returns either null or zero when accessing platform APIs, rather than throwing an exception. returnDefaultValues true // Encapsulates options for controlling how Gradle executes local unit tests. For a list // of all the options you can specify, read Gradle's reference documentation. all { // Sets JVM argument(s) for the test JVM(s). jvmArgs '-XX:MaxPermSize=256m' // You can also check the task name to apply options to only the tests you specify. if ( == 'testDebugUnitTest') { systemProperty 'debug', 'true' } ... } } } }

Run a test

To run a test, proceed as follows:

  1. Be sure your project is synchronized with Gradle by clicking Sync Project in the toolbar.
  2. Run your test in one of the following ways:
    • In the Project window, right-click a test and click Run .
    • In the Code Editor, right-click a class or method in the test file and click Run to test all methods in the class.
    • To run all tests, right-click on the test directory and click Run tests .

By default, your test runs using Android Studio's default run configuration. If you'd like to change some run settings such as the instrumentation runner and deployment options, you can edit the run configuration in the Run/Debug Configurations dialog (click Run > Edit Configurations).

View test coverage

The test coverage tool is available for local unit tests to track the percentage and areas of your app code that your unit tests have covered. Use the test coverage tool to determine whether you have adequately tested the elements, classes, methods, and lines of code that make up your app.

There are a number of ways to run a unit test, and they are described on the IntelliJ Running with Coverage page. The following procedure shows how to run a unit test inline from the editor:

  1. Double-click the unit test you want to run.
  2. In the editor, place your cursor in the line you want to run with coverage.
    • If you place your cursor in the class declaration, all test methods in that class run.
    • If you place your cursor in a method declaration, all code in that method runs.
    • If you place your cursor on a particular line within a method, only that line runs.
  3. Right-click the line where you placed your cursor.
  4. In the context menu, choose Run test-name with coverage.

    The coverage tool window appears.

Figure 2 shows the coverage tool window for a calculator unit test that tests for addition, subtraction, multiplication, and division.

Figure 2. See the code coverage percentages for your application.

For more information about local unit tests, see Building Local Unit Tests.

View the test results

When you run a JUnit or instrumented test, the results appear in the Run window. A green bar means all tests succeeded and a red bar means at least one test failed. Figure 1 shows a successful test run.

Figure 1. Test results appear in the Run window.

The Run window displays the tests in a tree view on the left, and the results and messages for the current test suite in the output pane on the right. Use the toolbars, context menus, and status icons to manage the test results, as follows:

  1. Use the run toolbar to rerun the current test, stop the current test, rerun failed tests (not shown because it is available for unit tests only), pause output, and dump threads.
  2. Use the testing toolbar to filter and sort test results. You can also expand or collapse nodes, show test coverage, and import or export test results.
  3. Click the context menu to track the running test, show inline statistics, scroll to the stacktrace, open the source code at an exception, auto scroll to the source, and select the first failed test when the test run completes.
  4. Test status icons indicate whether a test has an error, was ignored, failed, is in progress, has passed, is paused, was terminated, or was not run.
  5. Right-click a line in the tree view to display a context menu that lets you run the tests in debug mode, open the test source code file, or jump to the line in the source code being tested.

For more information about the Run window, its toolbars, and context menus, see the IntelliJ page, Test Runner Tab.

View inline statistics

To find out how long your tests took to run, do the following:

  1. Click the cog icon .
  2. In the drop-down list, select Show Inline Statistics.

    The elapsed time in milliseconds displays to the right of the tests.

Compare strings

If a unit test contains assertEquals() failures from comparing two string objects, you can see what the differences are between the two string objects to find out what caused the failures, as follows:

  1. In the output pane, click the Click to see difference link.
  2. In the Differences viewer, explore the differences as described on the IntelliJ page, Differences viewer for files.

Export test results

You can export your test results in XML or HTML format, as follows:

  1. Click Export Test Results .
  2. In the Export Test Results dialog, provide format and output information, and click OK.

    The exported test results save to the specified folder.

Import test results

You can import your exported test results, as follows:

  1. Click Import Test Results .
  2. In the drop-down menu, select the file you want to import.

    The imported tests results appear in the Run window.

Android: Тестирование приложения

Статья проплачена кошками - всемирно известными производителями котят.

Если статья вам понравилась, то можете поддержать проект.

Немного поработав в Android Studio и разобравшись в его структуре, вы, наверняка, замечали папки androidTest и test рядом с основной папкой с классами вашего проекта. Возможно, вы также слышали выражение от умных программистов, что приложение полностью покрыто тестами.

Зачем нужно тестирование и нужно ли оно вам? Если вы начинающий программист и пишете простые учебные примеры, то тесты вам не нужны. Даже если вы перешли от простых примеров к собственным разработкам средней сложности, то вполне можете обходиться без тестирования и дальше. Почему? Дело в том, что в небольших проектах вы в состоянии контролировать логику приложения. Вы можете предугадать слабые места и поправить код. Даже если вы что-то пропустили и выложили релиз в открытый доступ, то по отзывам пользователей вы можете быстро сориентироваться в проблеме и исправить ошибку.

Но всё меняется, если программа стала сложной. У вам появилось больше десятка различных экранов активностей, отдельных классов и т.д. Вы аккуратно стали разбивать код на модули, чтобы обеспечить независимость. Такой подход в обязательном порядке используется в компаниях, где каждый отвечает за свой участок кода. И тут вас подстерегает опасность. Вам доверили написать новый метод или переписать существующий метод, но вы ещё не до конца уяснили взаимодействие метода с другими кусками кода. Если метод в проекте был давно, то все уверены в его работе и фокусируются на новых задачах. Но вы сделали ошибку, например, банально опечатались и вместо плюса поставили минус - и числа стали вычитаться вместо сложения. Причём выводимые результаты могут быть вполне корректными для приложения. Поэтому при запуске приложения с неправильным методом программисты могут не заметить проблему. Проблему могут заметить позже сами пользователи, но если это приложение связано с банковским сектором, то несколько миллионов рублей, исчезнувших со счёта, не прибавит радости ни пользователю, ни руководству.

Как помогло бы тестирование. Для метода заводится проверка на сложение двух контрольных чисел, пусть будет 6 и 3. Когда группа программистов внесла свои правки в код, то запускается тестирование методов, в том числе и вашего метода. Теперь если вместо 9 (6 + 3) метод выдаст 3 (6 - 3), то тест не будет пройден. И вы будете сразу искать проблему в нужном месте.

Приблизительно так работают тесты - проверка на соответствие к ожидаемому результату.

Тесты делятся на две категории - локальные (Unit Testing) и инструментальные (UI Testing).

Unit Testing

Локальные тесты проверяют работу метода, класса, компонента. Тест не зависит от Android, по сути вы проверяете код Java, который можно проверить на обычном компьютере без участия устройства или эмулятора. Например, такому варианту соответствует сложение двух чисел типа int. Подобные тесты проводят в папке Test.

Популярными инструментами для юнит-тестов являются:

В build.gradle модуля приложения имеется строка для компиляции юнит-тестов.

testCompile 'junit:junit:4.12'

Локальные юнит-тесты

UI Testing

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

Инструменты для тестирования:

  • Espresso
  • UIAutomator
  • Robotium, Appium, Calabash, Robolectric

В build.gradle тесты представлены в виде строки.

androidTestCompile('', { exclude group: '', module: 'support-annotations' })

Часто для удобства приложение разделяют на несколько вариантов.

В build.gradle в секцию android добавляют блок

productFlavors { prod { } mock { applicationId "имя.вашего.пакета.mock" } } Указав другой идентификатор для mock, вы можете устанавливать вместе две разные версии приложения на одном устройстве. Рабочая версия будет использовать настройки по умолчанию из defaultConfig.

Тестирование Android приложений. C чего начать? - база знаний

Тестирование - тема очень многообразная. Разновидностей тестов масса, методик тестирования тоже, количество разнообразных инструментов просто огромно. Начинающему разобраться не просто. Но за что бороться есть, поскольку грамотная стратегия тестирования существенно улучшает качество приложения. 

Данная статья - это каталогизированный набор ссылок по теме тестирования Android приложений, с краткими аннотациями. Я создал его для того, чтобы самому было удобнее разбираться во всем этом материале и выбирать оптимальную стратегию тестирования собственных Android приложений. Надеюсь, этот набор ссылок пригодится и вам. 


В июне 2011 вышла книга, посвященная тестированию Android-приложений: Diego Torres Milano. Android Application Testing Guide. Книга добротная, написана хорошо.Блог автора так же содержит массу полезной информации. 

Официальная документация по встроенным средствам тестирования Android Developers Guide. Testing (перевод). Из недостатков: Android testing API основано на стиле JUnit 3 и не поддерживает JUnit 4. Тесты запускаются и работают на эмуляторе/девайсе, т.е. запуск медленный. 

Тестирование Android приложений - пример разработки небольшого Android-приложения с тестом на базе стандартного фреймворка android.test. 

Best practices for unit testing Android apps - обсуждение инструментов тестирования на stackoverflow. 

How to do Unit Testing on Android with Eclipse - видео, демонстрирующее создание тестового проекта в Eclipse. 

Автоматизированное тестирование мобильных приложений - обзор инструментов для тестирования интерфейса мобильных приложений. 

Серия курсов - Автоматизация мобильных приложений (в настоящее время курсов там мало, но анонс многообещающий). 

Шаблоны проектирования при разработке под Android. Часть 2 — MVP и Unit tests. Путь Джедая, Шаблоны проектирования при разработке под Android. Часть 3 — Пользовательский интерфейс, тестирование, AndroidMock - пара статей по теме тестирования на хабре. Содержание местами спорное, но комментарии, как всегда, интересные. 

Testing on android - весьма интересная презентация с полезными ссылками. 

Серия обзорных статей, посвященных тестированию мобильных приложений: Mobile Application Testing - Part I, part II, part III. 


При разработке под Android очень не удобно использовать короткие unit-тесты (раз статья, два статья). Дело в том, что стандартные тесты работают только на эмуляторе или на устройстве (т.к. зависят от Android API). Запуск тестов, в этом случае, становится достаточно длительным. 

Для ускорения работы можно выделять Android-независимые тесты в отдельный Java проект и запускать их на JVM компьютера, но это, конечно же, не решение проблемы. Вот дискуссия на stackoverflow: Best practices for unit testing Android apps. Основные варианты: использовать библиотеки Robolectric и Robotium . 

Библиотека Robolectric действительно решает проблему скорости запуска теста. Тесты запускаются не на эмуляторе/устройстве, а прямо на JVM компьютера, что на порядок быстрее. Robolectric позволяет тестировать большую часть функциональности Android, включая layouts, GUI, сервисы, работу с сетью, виджеты. К тому же, Robolectric использует синтаксис junit4. В то же время следует отдавать себе отчет в том, что Roboelectric эмулирует Android API. Точность и полнота такой эмуляции, естественно, не 100%. 

Introducing Calculon – a Java DSL for Android Activity testing - библиотека для удобного тестирования Activity. 


Про то, что такое mock-объекты и как их использовать, есть статьи на хабре: JMock и EasyMock: сравнение и howto в примерах и не только, Глоток МоКито. Mock-библиотек, работающих под Android, существует несколько: EasyMonkey, PowerMock, Android Mock,Mockito. 


MonkeyRunner - инструмент, входящий в состав Android SDK. С помощью MonkeyRunner можно писать программы на Питоне, способные установить Android-приложение, запустить его, послать ему последовательность нажатий клавиш, сделать и сохранить результирующий скриншот экрана. 

Robotium - фреймворк, дающий возможность разрабатывать тесты "черного ящика" для Android приложений. Тесты пишутся на Java. Для тестирования создается стандартный тестовый проект, в который добавляется библиотека Robotium. Тестовый проект можно запускать как на эмуляторе, так и на девайсе. Robotium использует синтаксис JUnit3. Полезная статья: Настройка среды для разработки Android приложений и автоматизации на Robotium. 

FoneMonkey for Android - бесплатный open source инструмент для тестирования rich interface, разработанный компанией Gorilla Logic (см. интервью с разработчиком FoneMonkey for Android, а так же статью в DrDobbs, посвященную FoneMonkey for IOS). Программа умеет записывать высокоуровневые action-based test automation скрипты на Java/Java Script, которые можно редактировать и (при необходимости) писать вручную. 

Sikuli - еще один бесплатный инструмент для автоматизации тестирования GUI. Особенность - скрипт, задающий последовательность действий, позволяет использовать скриншоты. Чтобы дать команду нажать кнопку, достаточно подставить в скрипт скриншот этой кнопки (используется специальная Sikuli IDE). Видео на youtubeнаглядно демонстрирует процесс создания скрипта. А вот пример видео, где sikuli "играет" в Angry birds. Вот пример использования sikuli для тестирования Android GUI. Преимущества и недостатки использования Sikuli для тестирования мобильных приложений приведены в презентации. 

T-PLAN ROBOT (VNCRobot) - универсальный инструмент для тестирования "черных ящиков" (видео, mobile testing brochure (pdf)). Есть платная и бесплатная open-source версия. 

На самом деле, инструментов, предназначенных для автоматизации тестирования приложений, очень много. Из платных отмечу: Eggplants,Test Quest, ZPX. Есть ещеJamo Solutions: M-eux test и SeeTest специально заточенные под мобильные приложения. 


При разработке Android-приложений важнейшая проблема - протестировать работу приложения на различных устройствах. Возможных вариантов устройств сотни, все себе не купишь. А платформо-железозависимые баги, к сожалению, совсем не редкость. 

Специальные сервисы предоставляют доступ к стендам, содержащим множество разнообразных устройств, и позволяют провести тестирование на всех этих устройствах разом. Таких сервисов как минимум три: Perfecto Mobile, Device Anywhereи TestDroid. Вот здесь описан принцип работы Device Anywhere и приведены скриншоты. Услуга удобная, но достаточно дорогая. 

TestDroid, кстати, позволяет записывать тесты в формате Robotium. 


uTest - сообщество из 45 тыс профессиональных тестеров из 180 стран. Реальные пользователи протестируют работу вашего приложения. Платный. 

The Beta Family - бесплатный сервис для тестирования приложения. Заводите аккаунт, заливаете бета-версию приложения, рассылаете приглашение на тестирование, обрабатываете результаты тестирования. На главной странице сайта написано, что сервис предназначен для тестирования iPhone/iPad/iPod приложений. Но Android так же поддерживается, о чем прямо написано в FAQ. Можно выбрать тип бета-тестеров: private или public. Если public, то ваше приложение смогут тестировать все желающие.

Appaloosa - сервис для приватного распространения приложения (например, среди доверенных бета-тестеров или среди работников вашей компании). Заводите аккаунт, даете доступ вашим знакомым бета-тестерам. После авторизации бета-тестеры получают возможность скачивать приложения, которые вы выложили на Appaloosa. Бесплатен на стадии бета тестирования, потом станет платным. 

Hockey Kit - еще один подобный сервис для распространения бета-версий среди своих бета-тестеров. 

Zubhium. Предоставляет SDK, с помощью которого вы в свое приложение встраиваете код для автоматического сбора информации об ошибках. Выкладываете бету. Ее тестируют в настоящий момент на стадии беты и поэтому - бесплатен. Бета тестеров нужно приглашать своих. 

PushLink. Еще один подобный сервис для приватного распространения приложений (например, бета версий). Добавляете в приложение немного кода для работы с PushLink. Собираете apk и отдаете бета-тестеру. Через некоторое время собираете новую версию apk и заливаете на PushLink. Пользователь автоматически получает уведомление о новой версии и скачивает ее с PushLink. Удобно - нет необходимости рассылать новые версии по email. Сервис бесплатен. 


Инструменты функционального тестирования — Monkey и MonkeyRunner - обзор двух стандартных инструментов: Monkey (стресс-тестирование) и MonkeyRunner("прокликивающие" тесты, сценарии тестов пишутся на Python). 

Android: Using monkey from Java - статья в блоге Diego Torres Milano, посвященная стандартной библиотеке chimpchat, эквиваленту monkeyrunner. 


Code coverage инструменты определяют степень покрытия кода тестами. 

Варианты для Android: EMMA, Robotium, Sonar, включающий Maven и Cobertura. Так же функциональость code coverage есть в бесплатном статическом анализаторе от Google - CodePro AnalytiX 


Библиотека ACRA - пишет креш-репорты в документ Google Docs. 

BugSense - real-time bug tracking service. 

Системы сбора статистики по работе приложения. 

Log collector - приложение для генерирования log-файла и отправки его по email. Удобно использовать в своих приложениях для реализации возможности отправки лога. 


Vogar - запуск большого количества тестов с записью истории выполнения тестов. 

Caliper - open-source фреймворк для создания микробенчмарков, их запуска и просмотра результатов. 

Android Junit Report - замена стандартному InstrumentationTestRunner с возможностью генерации XML-отчетов. 


Интересная презентация. 

Чек-лист для тестирования Android приложения: 

Best Practice Guidelines for developing quality mobile applications 

Android design guidelines 


How to test the 3G or Wi-Fi Connection speed on Iphone and Android Smartphones? 

Тестирование поведения приложения в условиях нехватки памяти 

Wide Area Network Emulator - позволяет разработчику эмулировать проблемы в сети - Network delay, Packet loss, Packet corruption, Disconnections, Packet re-ordering, Jitter и т.д. 


Test Driven Development, TDD: Разработка через тестирование. 

Behavior Driven Development, BDD::, фреймверк для BDD:JBehave 

Fitness:, - совместная работа клиентов, программистов и тестировщиков. GivWenZen - запись сценариев тестов простым английским языком.

Fundamentals of Testing | Android Developers

  1. Use an iterative development workflow
  2. Understand the Testing Pyramid
  3. Write small tests
    1. Robolectric
    2. Mock objects
    3. Instrumented unit tests
  4. Write medium tests
  5. Write large tests
    1. JUnit4 Rules
    2. Espresso
    3. UI Automator
    4. Android Test Orchestrator

Users interact with your app on a variety of levels, from pressing a Submit button to downloading information onto their device. Accordingly, you should test a variety of use cases and interactions as you iteratively develop your app.

Use an iterative development workflow

As your app expands, you might find it necessary to fetch data from a server, interact with the device's sensors, access local storage, or render complex user interfaces. The versatility of your app demands a comprehensive testing strategy.

When developing a feature iteratively, you start by either writing a new test or by adding cases and assertions to an existing unit test. The test fails at first because the feature isn't implemented yet.

It's important to consider the units of responsibility that emerge as you design the new feature. For each unit, you write a corresponding unit test. Your unit tests should nearly exhaust all possible interactions with the unit, including standard interactions, invalid inputs, and cases where resources aren't available.

Figure 1. The two cycles associated with iterative, test-driven development

The full workflow, as shown in Figure 1, contains a series of nested, iterative cycles where a long, slow, UI-driven cycle tests the integration of code units. You test the units themselves using shorter, faster development cycles. This set of cycles continues until your app satisfies every use case.

Understand the Testing Pyramid

Figure 2. The Testing Pyramid, showing the three categories of tests that you should include in your app's test suite

The Testing Pyramid, shown in Figure 2, illustrates how your app should include the three categories of tests: small, medium, and large:

  • Small tests are unit tests that you can run in isolation from production systems. They typically mock every major component and should run quickly on your machine.
  • Medium tests are integration tests that sit in between small tests and large tests. They integrate several components, and they run on emulators or real devices.
  • Large tests are integration and UI tests that run by completing a UI workflow. They ensure that key end-user tasks work as expected on emulators or real devices.

Although small tests are fast and focused, allowing you to address failures quickly, they're also low-fidelity and self-contained, making it difficult to have confidence that a passing test allows your app to work. You encounter the opposite set of tradeoffs when writing large tests.

Because of the different characteristics of each test category, you should include tests from each layer of the test pyramid. Although the proportion of tests for each category can vary based on your app's use cases, we generally recommend the following split among the categories: 70 percent small, 20 percent medium, and 10 percent large.

To learn more about the Android Testing Pyramid, see the Test-Driven Development on Android session video from Google I/O 2017, starting at 1:51.

Write small tests

As you add and change your app's functionality, make sure that these features behave as intended by creating and running unit tests against them. Although it's possible to evalute units on a device or emulator, it's usually quicker and easier to test the units in your development environment, adding stubbed or mocked methods as needed to interact with the Android system.

To learn about the characteristics of a well-defined small test, see the Test-Driven Development on Android session video from Google I/O 2017, starting at 6:49.


If your app's testing environment requires unit tests to interact more extensively with the Android framework, you can use Robolectric. This tool executes testing-friendly, Java-based logic stubs that emulate the Android framework. The community maintains these stubs.

Robolectric tests nearly match the full fidelity of running tests on an Android device while still executing more quickly than on-device tests. It also supports the following aspects of the Android platform:

  • Android 4.1 (API level 16) and higher
  • Android Gradle Plugin version 2.4 and higher
  • Component lifecycles
  • Event loops
  • All resources
Note: Robolectric has its own set of testing APIs and introduces some new concepts. For more information about integrating Robolectric's APIs with your app's tests, see the tool's user guide, as well as the Test-Driven Development on Android session video from Google I/O 2017, starting at 12:40.

Mock objects

You can monitor the elements of the Android framework with which your app interacts by running unit tests against a modified version of android.jar. This JAR file doesn't contain any code, so your app's calls to the Android framework throw exceptions by default. To test elements of your code that interact with the Android system, configure mock objects using a framework like Mockito.

If your code contains references to resources or complex interactions with the Android framework, you should use a different form of unit testing instead, such as Robolectric.

Instrumented unit tests

You can also run instrumented unit tests on a physical device or emulator, which doesn't involve any mocking or stubbing of the framework. Because this form of testing involves significantly slower execution times than local unit tests, however, it's best to rely on this method only when it's essential to evaluate your app's behavior against actual device hardware.

Write medium tests

After you've tested each unit of your app within your development environment, you should verify that the components behave properly when run on an emulator or device. Medium tests allow you to complete this part of the development process. These tests are particularly important to create and run if some of your app's components depend on physical hardware.

Medium tests evaluate how your app coordinates multiple units, but they don't test the full app. Examples of medium tests include service tests, integration tests, and hermetic UI tests that simulate the behavior of external dependencies.

Typically, it's better to test your app on an emulated device or a cloud-based service like Firebase Test Lab, rather than on a physical device, as you can test multiple combinations of screen sizes and hardware configurations more easily and quickly.

To learn more about how to write medium tests, see the Test-Driven Development on Android session video from Google I/O 2017, starting at 31:55.

Write large tests

Although it's important to test each layer and feature within your app in isolation, it's just as important to test common workflows and use cases that involve the complete stack, from the UI through business logic to the data layer.

If your app is small enough, you might need only one suite of large tests to evaluate your app's functionality as a whole. Otherwise, you should divide your large test suites by team ownership, functional verticals, or user goals.

Note: For each large, workflow-based test that you write, you should also write medium tests that check the functionality of each UI component included in the workflow. That way, your test suite can continue to identify potential issues within each step of a critical user journey, even when the corresponding large test keeps failing during one of the first few steps.

To learn more about how to write large tests, see the Test-Driven Development on Android session video from Google I/O 2017, starting at 30:38.

The AndroidJUnitRunner class defines an instrumentation-based JUnit test runner that lets you run JUnit 3- or JUnit 4-style test classes on Android devices. The test runner facilitates loading your test package and the app under test onto a device or emulator, running your tests, and reporting the results.

The AndroidJUnitRunner class also supports the following tools and frameworks from the Android Testing Support Library (ATSL):

JUnit4 Rules

ATSL includes code for managing the lifecycles of key app components involved in your tests, such as activities and services. To learn how to define these rules, see the JUnit4 Rules guide.


Espresso synchronizes asynchronous tasks while automating the following in-app interactions:

  • Performing actions on View objects.
  • Completing workflows that cross your app's process boundaries. Available only on Android 8.0 (API level 26) and higher.
  • Assessing how users with accessibility needs can use your app.
  • Locating and activating items within RecyclerView and AdapterView objects.
  • Validating the state of outgoing intents.
  • Verifying the structure of a DOM within WebView objects.
  • Tracking long-running background operations within your app.

To learn more about these interactions and how to use them in your app's tests, see the Espresso guide.

UI Automator

Caution: We recommend testing your app using UI Automator only when your app must interact with the system to fulfill a critical use case. Because UI Automator interacts with system apps and UIs, you need to re-run and fix your UI Automator tests after each system update. Such updates include Android platform version upgrades and new versions of Google Play services.

As an alternative to using UI Automator, we recommend adding hermetic tests or separating your large test into a suite of small and medium tests. In particular, focus on testing one piece of inter-app communication at a time, such as sending information to other apps and responding to intent results. The Espresso-Intents tool can help you write these smaller tests.

The UI Automator framework performs interactions within system apps on your app's behalf, such as inspecting the hierarchy of the currently-shown UI, taking screenshots, and analyzing the device's current state. For more details about how the UI Automator can observe an app under test, see the UI Automator guide.

Android Test Orchestrator

Android Test Orchestrator runs each UI test in its own Instrumentation sandbox, increasing your test suite's reliability by reducing shared state between tests and isolating app crashes on a per-test basis.

For more information about the benefits that Android Test Orchestrator provides as you test your app, see the Android Test Orchestrator guide, as well as the Test-Driven Development on Android session video from Google I/O 2017, starting at 23:58.

Test from the Command Line

This document describes how to create and run tests directly from the command line. This document assumes that you already know how to create a Android application in your programming environment.

Running Tests

You can run tests from the command-line, either with Gradle or with an Android Debug Bridge (adb) shell.

The Android plugin for Gradle lets you run unit tests from your Gradle project via the command-line. For more information on how to build unit tests for your app, see Building Effective Unit Tests.

Running unit tests with Gradle

The Android Plugin for Gradle lets you run unit tests from your Gradle project via the command-line. For more information on how to build unit tests for your app, see Building Effective Unit Tests.

The table below summarizes how to run your unit tests with Gradle:

Unit Test Type Command To Run Test Result Location
Local unit test Call the test task: ./gradlew test HTML test result files: path_to_your_project/module_name/build/reports/tests/ directory.

XML test result files: path_to_your_project/module_name/build/test-results/ directory.

Instrumented unit test Call the connectedAndroidTest task: ./gradlew connectedAndroidTest HTML test result files: path_to_your_project/module_name/build/outputs/reports/androidTests/connected/ directory.

XML test result files: path_to_your_project/module_name/build/outputs/androidTest-results/connected/ directory.

Gradle supports task name abbreviations. This means, for example, you can initiate the connectedAndroidTest task by simply entering the following command.

./gradlew cAT

The test and connectedAndroidTest tasks run tests on each module and build variant in your project. You can run tests for just a specific module in your project by prefixing the test or connectedAndroidTest task with the module name and a colon (:). For example, the following command runs instrumented unit tests for just the mylibrary module.

./gradlew mylibrary:connectedAndroidTest

You can also target a specific build variant using the following syntax.

Note: If you don't specify a target module to test, Gradle looks through all your modules and runs tests for each variant that matches the configuration name you specify.

Gradle also allows you to target specific tests using the --tests flag. For example, the following command runs only the sampleTestMethod tests for the specified build variant. To learn more about using the --tests flag, read Gradle's documentation on test filtering.

./gradlew testVariantNameUnitTest --tests *.sampleTestMethod
Multi-module reports

As described in table 1, Gradle saves test reports in the build/ directory of each module that it tests. However, when running tests across multiple modules, it may be useful to combine all the test results into a single report. To generate a single report when running tests across multiple modules, proceed as follows:

  1. In your project-level build.gradle file, add the following after all other configurations in the file. apply plugin: 'android-reporting'
  2. Invoke the test or connectedAndroidTest task with the mergeAndroidReports task. For example: ./gradlew connectedAndroidTest mergeAndroidReports

    If you want to skip test failures in order for Gradle to finish running all remaining tests, add the --continue option:

    ./gradlew connectedAndroidTest mergeAndroidReports --continue

When Gradle finishes running all your tests, it saves the combined reports in the PATH_TO_YOUR_PROJECT/build/ directory.

Running tests with ADB

When you run tests from the command-line with Android Debug Bridge (adb), you get more options for choosing the tests to run than with any other method. You can select individual test methods, filter tests according to their annotation, or specify testing options. Since the test run is controlled entirely from a command-line, you can customize your testing with shell scripts in various ways.

To run a test from the command-line, you run adb shell to start a command-line shell on your device or emulator, and then in the shell run the am instrument command. You control am and your tests with command-line flags.

As a shortcut, you can start an adb shell, call am instrument, and specify command-line flags all on one input line. The shell opens on the device or emulator, runs your tests, produces output, and then returns to the command-line on your computer.

To run a test with am instrument:

  1. If necessary, rebuild your main application and test package.
  2. Install your test package and main application Android package files (.apk files) to your current Android device or emulator
  3. At the command-line, enter: $ adb shell am instrument -w <test_package_name>/<runner_class>

    where <test_package_name> is the Android package name of your test application, and <runner_class> is the name of the Android test runner class you are using. The Android package name is the value of the package attribute of the manifest element in the manifest file (AndroidManifest.xml) of your test package. The Android test runner class is usually AndroidJUnitRunner.

    Your test results appear in STDOUT.

This operation starts an adb shell, then runs am instrument with the specified parameters. This particular form of the command will run all of the tests in your test package. You can control this behavior with flags that you pass to am instrument. These flags are described in the next section.

Using the am instrument Command

The general syntax of the am instrument command is:

am instrument [flags] <test_package>/<runner_class>

The main input parameters to am instrument are described in the following table:

Parameter Value Description
<test_package> The Android package name of the test package. The value of the package attribute of the manifest element in the test package's manifest file.
<runner_class> The class name of the instrumented test runner you are using. This is usually AndroidJUnitRunner.

The flags for am instrument are described in the following table:

Flag Value Description
-w (none) Forces am instrument to wait until the instrumentation terminates before terminating itself. The net effect is to keep the shell open until the tests have finished. This flag is not required, but if you do not use it, you will not see the results of your tests.
-r (none) Outputs results in raw format. Use this flag when you want to collect performance measurements, so that they are not formatted as test results. This flag is designed for use with the flag -e perf true (documented in the section Instrument options).
-e <test_options> Provides testing options as key-value pairs. The am instrument tool passes these to the specified instrumentation class via its onCreate() method. You can specify multiple occurrences of -e <test_options>. The keys and values are described in the section am instrument options. You can only use these key-value pairs with AndroidJUnitRunner or with InstrumentationTestRunner and its subclasses. Using them with any other class has no effect.

am instrument options

The am instrument tool passes testing options to AndroidJUnitRunner or InstrumentationTestRunner in the form of key-value pairs, using the -e flag, with this syntax:

-e <key> <value>

Some keys accept multiple values. You specify multiple values in a comma-separated list. For example, this invocation of AndroidJUnitRunner provides multiple values for the package key:

$ adb shell am instrument -w -e package, \ >

The following table lists the key-value pairs you can use with your test runner.

Key Value Description
package <Java_package_name> The fully-qualified Java package name for one of the packages in the test application. Any test case class that uses this package name is executed. Notice that this is not an Android package name; a test package has a single Android package name but may have several Java packages within it.
class <class_name> The fully-qualified Java class name for one of the test case classes. Only this test case class is executed.
<class_name>#method name A fully-qualified test case class name, and one of its methods. Only this method is executed. Note the hash mark (#) between the class name and the method name.
func true Runs all test classes that extend InstrumentationTestCase.
unit true Runs all test classes that do not extend either InstrumentationTestCase or PerformanceTestCase.
size [small | medium | large] Runs a test method annotated by size. The annotations are @SmallTest, @MediumTest, and @LargeTest.
perf true Runs all test classes that implement PerformanceTestCase. When you use this option, also specify the -r flag for am instrument, so that the output is kept in raw format and not re-formatted as test results.
debug true Runs tests in debug mode.
log true Loads and logs all specified tests, but does not run them. The test information appears in STDOUT. Use this to verify combinations of other filters and test specifications.
emma true Runs an EMMA code coverage analysis and writes the output to /data/<app_package>/ on the device. To override the file location, use the coverageFile key that is described in the following entry.

Note: This option requires an EMMA-instrumented build of the test application, which you can generate with the coverage target.

coverageFile <filename> Overrides the default location of the EMMA coverage file on the device. Specify this value as a path and filename in UNIX format. The default filename is described in the entry for the emma key.
-e Flag Usage Notes
  • am instrument invokes onCreate(Bundle) with a Bundle containing the key-value pairs.
  • The package key takes precedence over the class key. If you specifiy a package, and then separately specify a class within that package, Android will run all the tests in the package and ignore the class key.
  • The func key and unit key are mutually exclusive.

Usage examples

The following sections provide examples of using am instrument to run tests. They are based on the following structure:

  • The test package has the Android package name
  • Two instrumented test classes:
    • Foo1 which contains the test method bar1, and
    • Foo2 which contains test methods bar2 and bar3
  • The test runner is AndroidJUnitRunner.
Running the entire test package

To run all of the test classes in the test package, enter:

$ adb shell am instrument -w
Running all tests in a test case class

To run all of the tests in the class UnitTests, enter:

$ adb shell am instrument -w \ > -e class \ >

am instrument gets the value of the -e flag, detects the class keyword, and runs all the methods in the UnitTests class.

Selecting a subset of tests

To run all of the tests in Foo1, and the bar3 method in Foo2, enter:

$ adb shell am instrument -w \ > -e class, \ >

Create UI Tests with Espresso Test Recorder

The Espresso Test Recorder tool lets you create UI tests for your app without writing any test code. By recording a test scenario, you can record your interactions with a device and add assertions to verify UI elements in particular snapshots of your app. Espresso Test Recorder then takes the saved recording and automatically generates a corresponding UI test that you can run to test your app.

Espresso Test Recorder writes tests based on the Espresso Testing framework, an API in the Android Testing Support Library. The Espresso API encourages you to create concise and reliable UI tests based on user actions. By stating expectations, interactions, and assertions without directly accessing the underlying app’s activities and views, this structure prevents test flakiness and optimizes test run speed.

Turn off animations on your test device

Before using Espresso Test Recorder, make sure you turn off animations on your test device to prevent unexpected results. Follow the "Set Up Espresso" instructions on the Testing UI for a Single App page, but note that you do not need to manually set a dependency reference to the Espresso library because Test Recorder does this automatically when you save a recording. These steps only need to be done once for a given project.

Record an Espresso test

Espresso tests consist of two primary components: UI interactions and assertions on View elements. UI interactions include tap and type actions that a person may use to interact with your app. Assertions verify the existence or contents of visual elements on the screen. For example, an Espresso test for the Notes testing app might include UI interactions for clicking on a button and writing a new note but would use assertions to verify the existence of the button and the contents of the note.

This section will go over how to create both of these test components using Espresso Test Recorder, as well as how to save your finished recording to generate the test.

Record UI interactions

To start recording a test with Espresso Test Recorder, proceed as follows:

  1. Click Run > Record Espresso Test.
  2. In the Select Deployment Target window, choose the device on which you want to record the test. If necessary, create a new Android Virtual Device. Click OK.
  3. Espresso Test Recorder triggers a build of your project, and the app must install and launch before Espresso Test Recorder allows you to interact with it. The Record Your Test window appears after the app launches, and since you have not interacted with the device yet, the main panel reads "No events recorded yet." Interact with your device to start logging events such as "tap" and "type" actions.

Note: Before you can begin logging interactions, you may see a dialog on your device that says "Waiting for Debugger" or "Attaching Debugger." Espresso Test Recorder uses the debugger to log UI events. When the debugger attaches, the dialog will close automatically; do not hit Force Close.

Recorded interactions will appear in the main panel in the Record Your Test window, as shown in figure 1 below. When you run the test, the Espresso test will try executing these actions in the same order.

Figure 1. The Record Your Test window with logged UI interactions.

Add assertions to verify UI elements

Assertions verify the existence or contents of a View element through three main types:

  • text is: Checks the text content of the selected View element
  • exists: Checks that the View element is present in the current View hierarchy visible on the screen
  • does not exist: Checks that the View element is not present in the current View hierarchy

To add an assertion to your test, proceed as follows:

  1. Click Add Assertion. A Screen Capture dialog appears while Espresso gets the UI hierarchy and other information about the current app state. The dialog closes automatically once Espresso has captured the screenshot.
  2. A layout of the current screen appears in a panel on the right of the Record Your Test window. To select a View element on which to create an assertion, click on the element in the screenshot or use the first drop-down menu in the Edit assertion box at the bottom of the window. The selected View object is highlighted in a red box.
  3. Select the assertion you want to use from the second drop-down menu in the Edit assertion box. Espresso populates the menu with valid assertions for the selected View element.
    • If you choose the "text is" assertion, Espresso automatically inserts the text currently inside the selected View element. You can edit the text to match your desired assertion using the text field in the Edit assertion box.
  4. Click Save and Add Another to create another assertion or click Save Assertion to close the assertion panels.

The screenshot in figure 2 shows a "text is" assertion being created to verify that the title of the note is "Happy Testing!":

Figure 2. The Edit assertion box after a View element is selected (in red).

While creating an assertion, you can continue interacting with your app, even with the assertion panels still open within the Record Your Test window. Espresso Test Recorder will keep logging your actions, but the assertion you are editing will appear before these interactions once it’s saved. The screenshot for the assertion also retains the layout that the device or emulator had at the time you hit the Add Assertion button.

Save a recording

Once you finish interacting with your app and adding assertions, use the following steps to save your recording and generate the Espresso test:

  1. Click Complete Recording. The Pick a test class name for your test window appears.
  2. Espresso Test Recorder gives your test a unique name within its package based on the name of the launched activity. Use the Test class name text field if you want to change the suggested name. Click Save.
    • If you have not added the Espresso dependencies to your app, a Missing Espresso dependencies dialog appears when you try to save your test. Click Yes to automatically add the dependencies to your build.gradle file.
  3. The file automatically opens after Espresso Test Recorder generates it, and Android Studio shows the test class as selected in the Project window of the IDE.
    • Where the test saves depends on the location of your instrumentation test root, as well as the package name of the launched activity. For example, tests for the Notes testing app save in the src > androidTest > java > com.example.username.appname folder of the app module on which you recorded the test.

Run an Espresso test locally

To run an Espresso test, use the Project window on the left side of the Android Studio IDE:

  1. Open the desired app module folder and navigate to the test you want to run. The test’s location depends on the location of your instrumentation test root and the package name of the launched activity. The following examples demonstrate where a test would save for the Notes testing app:
    • If you are using the Android view within the window, navigate to java > com.example.username.appname (androidTest).
    • If you are using the Project view inside the window, navigate to src > androidTest > java > com.example.username.appname within the module folder.
  2. Right-click on the test and click Run ‘testName.’
    • Alternatively, you can open the test file and right-click on the generated test class or method. Read more about how to run tests on the Test Your App page.
  3. In the Select Deployment Target window, choose the device on which you want to run the test. If necessary, create a new Android Virtual Device. Click OK.

Monitor the progress of your test in the Run window at the bottom of the IDE. Android Studio runs a full build of your project and opens a tab with the name of your test in the Run window, as shown in figure 3. You can check whether your test passes or fails in this tab, as well as how long the test took to run. When the test finishes, the tab will log "Tests ran to completion."

Figure 3. Sample output in the Run window after running an Espresso test locally.

To learn more about writing test run configurations, read the "Defining a test configuration for a class or method" section in Create and Edit Run/Debug Configurations.

Run an Espresso test with Firebase Test Lab for Android

You can use tests generated by Espresso Test Recorder with Firebase Test Lab to test your app in the cloud on hundreds of device configurations. There is no charge to test your app with Test Lab within the free daily quota on the Spark plan. To run Espresso tests with Firebase Test Lab, create a Firebase project for your app and then follow the instructions to Run your tests with Firebase Test Lab from Android Studio.

Figure 4. Sample output in the Run window after running a test with Firebase Test Lab on multiple devices.

android.test | Android Developers

A framework for writing Android test cases and suites.

ActivityInstrumentationTestCase<T extends Activity> This class was deprecated in API level 3. new tests should be written using ActivityInstrumentationTestCase2, which provides more options for configuring the Activity under test   ActivityInstrumentationTestCase2<T extends Activity> This class was deprecated in API level 24. Use ActivityTestRule instead. New tests should be written using the Android Testing Support Library.   ActivityTestCase This class was deprecated in API level 24. New tests should be written using the Android Testing Support Library.   ActivityUnitTestCase<T extends Activity> This class was deprecated in API level 24. Write Local Unit Tests instead.   AndroidTestCase This class was deprecated in API level 24. Use InstrumentationRegistry instead. New tests should be written using the Android Testing Support Library.   AndroidTestRunner This class was deprecated in API level 24. Use AndroidJUnitRunner instead. New tests should be written using the Android Testing Support Library.   ApplicationTestCase<T extends Application> This class was deprecated in API level 24. Use InstrumentationRegistry instead. New tests should be written using the Android Testing Support Library.   InstrumentationTestCase This class was deprecated in API level 24. Use InstrumentationRegistry instead. New tests should be written using the Android Testing Support Library.   InstrumentationTestRunner This class was deprecated in API level 24. Use AndroidJUnitRunner instead. New tests should be written using the Android Testing Support Library.   InstrumentationTestSuite This class was deprecated in API level 24. Use InstrumentationRegistry instead. New tests should be written using the Android Testing Support Library.   IsolatedContext This class was deprecated in API level 24. New tests should be written using the Android Testing Support Library.   LoaderTestCase A convenience class for testing Loaders.  MoreAsserts This class was deprecated in API level 24. Use Hamcrest matchers instead.   ProviderTestCase<T extends ContentProvider> This class was deprecated in API level 3. this class extends InstrumentationTestCase but should extend AndroidTestCase. Use ProviderTestCase2, which corrects this problem, instead.   ProviderTestCase2<T extends ContentProvider> This test case class provides a framework for testing a single ContentProvider and for testing your app code with an isolated content provider.  RenamingDelegatingContext This class was deprecated in API level 24. New tests should be written using the Android Testing Support Library.   ServiceTestCase<T extends Service> This class was deprecated in API level 24. Use ServiceTestRule instead. New tests should be written using the Android Testing Support Library.   SingleLaunchActivityTestCase<T extends Activity> This class was deprecated in API level 24. Use ActivityTestRule instead. New tests should be written using the Android Testing Support Library.   SyncBaseInstrumentation This class was deprecated in API level 24. Use InstrumentationRegistry instead. New tests should be written using the Android Testing Support Library.   TouchUtils This class was deprecated in API level 24. Use Espresso UI testing framework instead. New tests should be written using the Android Testing Support Library.   ViewAsserts This class was deprecated in API level 24. Use Espresso View Matchers instead. New test should be written using the Android Testing Support Library. For more information about UI testing, take the Espresso UI testing training.

Смотрите также