Java class testing android

Developing Android unit and instrumentation tests — Tutorial

This tutorial describes how to write unit and instrumentation tests for your Android application. It describes how to execute these tests via Android studio and Gradle. This tutorial assumes that you are familiar with Android programming in general.

1. Introduction into Android testing

1.1. Testing Android applications

Android applications run on a variety of devices. Also the Android framework and the surrounding open source frameworks evolve at a high speed. To ensure that you application works well, it is import to write software tests. This helps you to enhance and maintain the Android application.

Unit testing for Android can be classified into:

Local unit tests — tests which can run on the JVM.

Instrumented unit tests — tests which require the Android system.

Local unit tests run much faster compared to the time required to deploy and run tests on an Android device. Prefer writing local unit tests and only run tests on Android, if you require a real Android system.

If you write local unit test and have dependencies to Android API, you need to replace them, e.g., via a mocking framework like Mockito.

1.2. What to test on Android applications

Your test should focus on the business logic of your application. A good rule of thumb is to have the following distribution of tests:

70-80 % unit tests to ensure stability of your code basis

20-30 % functional tests to ensure that the application really works

some cross functional tests if your application integrates intensively with other Application components

You should test your application at least on one device with the lowest possible configuration. In addition you should test on one device with the highest available configuration, e.g., pixel density, screen resolution to ensure that it works fine on these devices.

1.3. Tooling support for Android testing

The Android Testing Support library (ATSL) project from Google provides tooling for Android testing. For example, it ( AndroidJUnitRunner ).

If you run local unit tests, a special version of the android.jar (also known as the Android mockable jar ) is created by the tooling. This modified JAR file is provided to the unit test so that all fields, methods and classes are available. Any call to the Android mockable JAR results, by default, in an exception, but you can configure Android to return default values. See Activating default return values for mocked methods in android.jar for details.

The library provides a JUnit 4-compatible test runner ( AndroidJUnitRunner ), the Espresso test framework and the UI Automator test framework. Espresso test framework can be used to test the User Interface of your application. UI Automator allows to write cross application functional tests.

AndroidJunitRunner provides access to the instrumentation API, via the InstrumentationRegistery .

InstrumentationRegistry.getInstrumentation() , returns the Instrumentation currently running.

InstrumentationRegistry.getContext() , returns the Context of this Instrumentation’s package.

InstrumentationRegistry.getTargetContext() , returns the application Context of the target application.

InstrumentationRegistry.getArguments() , returns a copy of arguments Bundle that was passed to this Instrumentation. This is useful when you want to access the command line arguments passed to the instrumentation for your test.

It also gives access to the life cycle via the ActivityLifecycleMonitorRegistry .

1.4. Android project organization for tests

The following is the default directory structure for your application and test code:

app/src/main/java — for your source code of your main application build

app/src/test/java — for any unit test which can run on the JVM

app/src/androidTest/java — for any test which should run on an Android device

If you follow this conversion, the Android build system runs your tests on the correct target (JVM or Android device).

If you receive the following error message: «error duplicate files in path. Path in archive: LICENSE.txt» you can add the following to your app/gradle.build file.

2. Android unit testing

2.1. Unit testing in Android

A unit test verifies in isolation the functionality of a certain component. For example, assume a button in an Android activity is used to start another activity. A unit test would determine, if the corresponding intent was issued, not if the second activity was started

A unit tests for an Android application can be:

local unit test — which runs on the JVM

Android unit test — which runs on the Android runtime

If they run on the JVM, they are executed against a modified version of the android.jar Android library. In this version all final modifiers have been stripped off. This makes it easier to use mocking libraries, like Mockito.

The local unit tests of an Android project should be located in the app/src/test folder.

2.2. Required dependencies in the Gradle build file

To use JUnit tests for your Android application, you need to add it as dependency to your Gradle build file.

2.3. Running the unit tests

2.3.1. Using Gradle

Run your unit tests with the gradlew test command.

2.3.2. Using Android Studio

To run a unit test, right-click on your test class in the Project window and select Run.

2.4. Location of test reports

The Test reports are created in the app/build/reports/tests/debug/ directory. The index.html gives an overview and links to the individual test pages.

2.5. Activating default return values for mocked methods in android.jar

By default, all calls to methods in the modified android.jar file throw exceptions. This default should ensure that your unit tests only test your code and do not depend on any particular behavior of the Android platform. If you want to configure a certain behavior, you can use a mocking framework to replace these call.

You can also instruct the Gradle build system to return default values for method calls in the `android.jar`with the following configuration in your Gradle build file.

3. Exercise: Create unit test

In this exercise you learn how to create a simple JUnit4 test for an Android project.

3.1. Preparation: Create Android project

Create the Android project as described in Android temperature converter.

3.2. Add JUnit dependency

Ensure you have the dependency to Junit in your app/build.gradle file.

3.3. Create test

In your app/src/test directory create the following two test methods for the ConverterUtil class.

3.4. Run unit tests

Ensure your unit tests are correctly implemented by running test tests. They should run successfully.

4. Writing tests to run on the Android device

4.1. Instrumentation tests

The Android testing API provides hooks into the Android component and application life cycle. These hooks are called the instrumentation API and allow your tests to control the life cycle and user interaction events.

Under normal circumstances your application cannot control the life cycle events and the user drives the application. For example, if Android creates your activity the onCreate() method is called. Or if the user presses a button your corresponding code is called. Via instrumentation you can control these events via your test code. For example, your instrumentation test can start the activity. Afterwards, it can call the finish() and restart the activity to test if the instance state of the activity is correctly restored.

Instrumented unit tests are unit tests that run on Android devices and emulators instead of running on the Java virtual machine. These tests have access to the real device and its resources and are useful to unit test functionality which cannot be easily mocked by mocking frameworks. An example is a test which validates a Parcelable implementation.

An instrumentation-based test class allows you to send key events (or touch events) to the application under test.

With user interface testing framework like Espresso, the developer rarely has to use the instrumentation API directly.

4.2. How the Android system executes tests

The InstrumentationTestRunner is the base test runner for Android tests. This test runner starts and loads the test methods. Via the instrumentation API it communicates with the Android system. If you start a test for an Android application, the Android system kills any process of the application under test and then loads a new instance. It does not start the application, this is the responsibility of the test methods. The test method controls the life cycle of the components of the application.

The test runner also calls the onCreate() method of the application and activity under test during its initialization.

4.3. Mocking objects in Android

The mocking framework Mockito can also be used for instrumentation tests. This allows you to replace parts of the Android system which are not interesting for the test. The Android framework provided in the past specialized mocking classes but these are not necessary anymore.

4.4. Location of instrumentation tests

As described in Android project organization for tests the unit tests of an Android project should be located in the app/src/androidTest/java folder.

4.5. Define dependencies and testInstrumentationRunner in the Gradle build file

To use JUnit tests for your Android application you need to add the dependency to JUnit to your Gradle build file. You also need to specify android.support.test.runner.AndroidJUnitRunner as testInstrumentationRunner in the build file.

4.6. Using the @RunWith(AndroidJUnit4.class)

It is also recommended annotating the test with the @RunWith(AndroidJUnit4.class) annotation. AndroidJUnit4 extends JUnit4, so if you use pure Junit4 syntax and ActivityTestRule it is not required. But you need it, if you want to run, i.e., Espresso tests with ActivityTestRule and JUnit4.

4.7. Run the tests on Android

Run your local unit tests via Gradle with the gradlew connectedCheck command.

To run your local unit tests via Android Studio, right-click on your test class in the Project window and select Run.

4.8. Location of test reports

The test reports are created in the app/build/reports/androidTests/connected/ directory. The index.html gives an overview and links to the individual test pages.

4.9. How to replace the application for instrumentation tests

You can replace the application class for the instrumentation tests by overriding the AndroidJUnitRunner and its newApplication method.

Источник

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

Тестирование — одна из важнейших частей разработки качественных программных продуктов. Сегодня мы поговорим о некоторых методологиях и библиотеках, разработанных и используемых нашей командой для написания тестов Android приложений.

Начнем с самых базовых вещей, потому более опытные разработчики могут перейти сразу к разделу об инструментах для UI тестирования. Для тех, кому хочется узнать или освежить базовые вещи — приятного чтения.

Создание первого теста

Создадим небольшой компонент, который и будем тестировать. Он парсит файл с JSON объектом, содержащим имя, и возвращает полученную строку:

Тут и в дальнейшем я буду приводить сокращенную версию кода. Полную версию можно посмотреть в репозитории. К каждому сниппету будет приложена ссылка на полный код.

Теперь напишем первый JUnit тест. JUnit — это Java библиотека для написания тестов. Для того, чтобы JUnit знал, что метод является тестом, нужно добавить к нему аннотацию @Test . JUnit содержит в себе класс Assert , который позволяет сравнивать фактические значения с ожидаемыми и выводит ошибку, если значения не совпадают. Этот тест будет тестировать корректность нашего компонента, а именно чтения файла, парсинга JSON и получения верного поля:

Библиотеки для написания тестов

Тесты — это тоже код, который надо поддерживать. Более того, код тестов должен быть прост для понимания, чтобы его можно было верифицировать в уме. Потому есть смысл инвестировать в упрощение кода тестов, избавление от дублирования и повышение читабельности. Посмотрим на широко используемые библиотеки, которые помогут нам в этом деле.

Чтобы не дублировать код подготовки в каждом тесте, существуют аннотации @Before и @After . Методы, помеченные аннотацией @Before , будут выполняться перед каждым тестом, а помеченные аннотацией @After — после каждого теста. Также есть аннотации @BeforeClass и @AfterClass , которые выполняются соответственно перед и после всех тестов в классе. Давайте переделаем наш тест, используя такие методы:

Мы смогли убрать дублирование кода настройки каждого теста. Однако, много разных классов с тестами могут потребовать создания файла, и это дублирование тоже хотелось бы убрать. Для этого есть библиотека тестовых правил (TestRule). Тестовое правило выполняет функцию схожую с @Before и @After . В методе apply() этого класса мы можем выполнить нужные нам действия до и после выполнения каждого или всех тестов. Помимо уменьшения дублирования кода, преимущество такого метода заключается еще и в том, что код выносится из класса тестов, что уменьшает количество кода в тесте и облегчает его чтение. Напишем правило для создания файла:

Используем это правило в нашем тесте. Для того, чтобы действия TestRule исполнялись для каждого теста, нужно пометить TestRule аннотацией @Rule .

Если правило отметить аннотацией @ClassRule , то действия будут вызываться не перед каждым тестом, а один раз перед всеми тестами в классе, аналогично аннотациям @BeforeClass и @AfterClass .

Когда в тестах используется несколько TestRule , может понадобиться, чтобы они запускались в определенном порядке, для этого существует RuleChain с помощью которого можно определить порядок запуска наших TestRule . Создадим правило, которое должно создать папку до того, как будет создан файл:

С этим правилом класс с тестом будет выглядеть следующим образом:

Теперь в каждом тесте директория будет создаваться перед созданием файла и удаляться после удаления файла.

Google Truth — это библиотека для улучшения читабельности кода тестов. Содержит методы assert (аналогично JUnit Assert), но более читабельные для человека, а также включает гораздо больше вариантов для проверки параметров. Так выглядит предыдущий тест с использование Truth:

Видно, что код читается почти как текст на разговорном английском языке.

Наш компонент делает две разных работы: читает файл и парсит его. Чтобы придерживаться принципа единственной ответственности, давайте выделим логику чтения файла в отдельный компонент:

Сейчас мы хотим тестировать именно NameRepository , а фактически тестируем и чтение файла в FileReader . Чтобы этого избежать и тем самым повысить изоляцию, надежность и скорость выполнения теста, мы можем заменить реальный FileReader на его мок.

Mockito — библиотека для для создания заглушек (моков) вместо реальных объектов для использования их в тестах. Некоторые действия, которые можно выполнять с помощью Mockito:
создавать заглушки для классов и интерфейсов;
проверять вызовы метода и значения передаваемые этому методу;
подключение к реальному объекту «шпиона» spy для контроля вызова методов.

Создадим мок FileReader и настроим его так, чтобы метод readFile() возвращал нужную нам строку:

Теперь не происходит никакого чтения файла. Вместо этого, мок отдает настроенное в тесте значение.

Использование моков имеет свои преимущества:

• тесты проверяют только тестируемый класс на ошибки, ошибки других классов на проверку тестируемого класса никак не влияют
• иногда более короткий и читабельный код
• есть возможность проверять вызовы метода и передаваемые значения методам мокированного объекта

• по умолчанию ненастроенные методы возвращают null, потому все используемые методы нужно настраивать явно.
• если реальный объект имеет состояние, то при каждом его предполагаемом изменении нужно перенастраивать его мок, из-за чего код тестов иногда раздувается.

Существует более простой и удобный способ создания моков — использовать специальную аннотацию @Mock :

Есть три способа инициализировать такие моки:

Второй вариант максимально декларативен и компактен, но требует использования специального раннера тестов, что не всегда удобно. Последний вариант лишен этого недостатка и более декларативен, чем использование метода initMocks() .

Host Java VM vs Android Java VM

Android тесты можно поделить на два типа: те, что можно запускать на обычной Java VM, и те, что необходимо запускать на Android Java VM. Давайте посмотрим на оба типа тестов.

Тесты, запускаемые на обычной Java VM

Тесты для кода, не требующего работы компонентов Android API, для работы которых нужен Android-эмулятор или реальное устройство, можно запускать прямо на вашем компьютере и на любой Java-машине. Преимущественно это юнит-тесты бизнес-логики, которые тестируют изолированно отдельно взятый класс. Гораздо реже пишутся интеграционные тесты, так как далеко не всегда есть возможность создать реальные объекты классов, с которыми взаимодействует тестируемый класс.

Чтобы написать класс с Host Java тестами нужно, чтобы java файл имел путь $/src/test/java/. . Также с помощью @RunWith аннотации указать Runner , который отвечает за запуск тестов, корректный вызов и обработку всех методов:

Использование этих тестов имеет множество преимуществ:

• не требуют запуска эмулятора или реального устройства, особенно это важно при прохождении тестов в Continuous integration, где эмулятор может работать очень медленно и нет реального устройства
• очень быстро проходят, так как для этого не нужно запускать приложение, отображать UI и т.д.
• стабильны, так как нет проблем, связанных с тем, что эмулятор может зависнуть и т.д.

с другой стороны, этими тестами:

• нельзя в полной мере протестировать взаимодействие классов с операционной системой
• в частности, нельзя протестировать нажатия на UI элементы и жесты

Для того, чтобы была возможность использовать Android API классы в Host Java тестах, существует библиотека Robolectric, которая эмулирует среду Android и дает доступ к ее основным функциям. Однако, тестирование классов Android с Roboelectric часто работает нестабильно: нужно время, пока Robolectric будет поддерживать последнее API Android, существуют проблемы с получением ресурсов и т.д. Поэтому реальные классы почти не используются, а используются их моки для юнит-тестирования.

Для запуска тестов с помощью Roboelectric нужно установить кастомный TestRunner. В нем можно настроить версию SDK (самая последняя стабильная версия — 23), обозначить основной класс Application и другие параметры для эмулированной среды Android.

Тесты, запускаемые на Android Java VM

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

Чтобы написать тест для Android Java VM нужно положить java файл по пути $/src/androidTest/java/. , а также с помощью @RunWith аннотации указать AndroidJUnit4 , который позволит запускать тесты на устройстве Android.

UI тесты

Для тестирования UI используется фреймворк Espresso, который предоставляет API для тестирования пользовательского интерфейса программы. В Espresso тесты работают в бэкграунд потоке, а взаимодействие с UI элементами в потоке UI. Espresso имеет несколько основных классов для тестирования:

• Espresso — основной класс. Содержит в себе статические методы, такие как нажатия на системные кнопки (Back, Home), вызвать/спрятать клавиатуру, открыть меню, обратится к компоненту.
• ViewMatchers — позволяет найти компонент на экране в текущей иерархии.
• ViewActions — позволяет взаимодействовать с компонентом (click, longClick, doubleClick, swipe, scroll и т.д.).
• ViewAssertions — позволяет проверить состояние компонента.

Первый UI тест

Напишем простейшее Android-приложение, которое и будем тестировать:

Протестируем наше приложение. При тестировании UI прежде всего нужно запустить Activity. Для этого существует ActivityTestRule, которое запускает Activity перед каждым тестом и закрывает после:

Напишем простой тест, проверяющий, что элемент с id R.id.container показан на экране:

Разблокировка и включение экрана

Эмулятор на слабых или загруженных машинах может работать медленно. Поэтому между запуском эмулятора и окончанием билда с установкой приложения на эмулятор может пройти достаточно времени для того, чтобы экран заблокировался от бездействия. Таким образом тест может быть запущен при заблокированном экране, что вызовет ошибку java.lang.RuntimeException: Could not launch activity within 45 seconds . Поэтому перед запуском Activity нужно разблокировать и включить экран. Раз это нужно делать в каждом UI тесте, для избежания дублирования кода создадим правило, которое будет разблокировать и включать экран перед тестом:

Напишем кастомное ActivityTestRule , которое разблокирует экран эмулятора и запустит активити перед запуском тестов:

Используя это правило вместо стандартного можно сильно снизить число случайных падений UI тестов в CI.

Тестирование фрагментов

Обычно верстка и логика UI приложения не кладется вся в активити, а разбивается на окна, для каждого из которых создается фрагмент. Давайте создадим простой фрагмент для вывода на экран имени с помощью NameRepository :

При открытии фрагмента UI может зависнуть на некоторое время, а если используются анимации переходов между фрагментами, тест может начаться до появления фрагмента. Поэтому нужно не просто открыть фрагмент, а дождаться, когда он будет запущен. Для ожидания результата выполнения действий отлично подходит библиотека Awaitility, которая имеет очень простой и понятный синтаксис. Напишем правило, запускающее фрагмент и ожидающее его запуска с помощью этой библиотеки:

В данном случае выражение означает, что если в течении пяти секунд фрагмент не запустится, то тест не будет пройден. Нужно отметить, что как только фрагмент запустится, тест сразу же продолжит выполнение и не будет ждать все пять секунд.

Аналогично правилу, которое запускает активити, логично создать правило, которое запускает фрагмент:

Тест фрагмента с использованием этого правила будет выглядеть следующим образом:

Асинхронная загрузка данных во фрагментах

Так как операции с диском, а именно получение имени из файла, может выполняться сравнительно долго, то следует эту операцию выполнять асинхронно. Для асинхронного получения имени из файла используем библиотеку RxJava. Можно уверенно сказать, что RxJava сейчас используется в большинстве Android приложений. Практически каждая задача, которую нужно выполнить асинхронно, выполняется с помощью RxJava, потому что это пожалуй одна из самых удобных и понятных библиотек для асинхронного выполнения кода.

Изменим наш репозиторий так, чтобы он работал асинхронно:

Для тестирования RX-кода существует специальный класс TestObserver , который автоматически подпишется на Observable и мгновенно получит результат. Тест репозитория будет выглядеть следующим образом:

Обновим наш фрагмент, используя новый реактивный репозиторий:

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

Когда во фрагменте или активити выполняются асинхронные действия, в данном случае — чтение имени из файла, нужно иметь ввиду, что фрагмент может быть закрыт пользователем до того, как асинхронное действие выполнится. В текущей версии фрагмента допущена ошибка, так как если при выполнении асинхронной операции фрагмент будет уже закрыт, то textView будет уже удален и равен null . Чтобы не допустить краша приложения с NullPointerException при доступе к textView в subscribe() , остановим асинхронное действие при закрытии фрагмента:

Для тестирования подобных ошибок, связанных с асинхронными действиям во фрагменте, нужно закрыть фрагмент сразу же после его открытия. Это можно сделать просто заменив его на другой фрагмент. Тогда при завершении асинхронного действия onCreateView в закрытом фрагменте textView будет null и если допустить ошибку и не отменить подписку, приложение упадет. Напишем правило для тестирования на эту ошибку:

Добавим это правило в класс тестов фрагмента:

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

Юнит-тестирование Rx кода

Создадим презентер, куда мы вынесем логику подписки на возвращаемый репозиторием Observable из фрагмента, а также добавим timeout для получения имени из файла:

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

В данном тесте презентер не вызовет никакой метод объекта listener , так как тест проходит прежде, чем выполняется асинхронное действие. В тестах на эмуляторе Awaitility решает эту проблему. В юнит-тестах тестирование асинхронной природы кода не совсем к месту, а потому в них можно заменить стандартные RxJava Schedulers на синхронные. Используем для этого TestScheduler, который позволяет произвольно установить время, которое якобы прошло с момента подписки на Observable , чтобы протестировать корректную установку таймаута. Как обычно, напишем для этого правило:

Тест презентера с новым правилом будет выглядеть следующим образом:

Тестирование кода, использующего Dagger 2

Для облегчения работы с графом зависимостей объектов отлично подходит паттерн Dependency Injection. Dagger 2 — это библиотека, которая поможет в реализации этого паттерна. Поэтому в большинстве наших Android приложений все компоненты предоставляются с помощью Dagger. Об использовании и преимуществах этой библиотеки можно написать отдельную статью, а тут мы рассмотрим, как тестировать приложения, её использующие.

Начнем с того, что практически всегда при использовании Dagger существует ApplicationComponent , который предоставляет все основные зависимости приложения, и инициализируется в классе приложения Application , который, в свою очередь, имеет метод для получения этого компонента.

Также создадим Dagger модуль, который будет предоставлять репозиторий:

Изменим фрагмент следующим образом, чтобы репозиторий получать с помощью Dagger:

Помимо функциональных тестов UI хорошо иметь и unit-тесты с замоканными зависимостями. Чтобы предоставлять мокированные объекты с помощью Dagger, нужно заменить ApplicationComponent на специально созданный компонент для тестов. В первую очередь создадим метод для подмены основного компонента в Application :

Чтобы не заменять компонент в каждом классе с тестами фрагментов, создадим для этого правило:

Отметим, что нужно вернуть оригинальный компонент после теста, так как Application создается один для всех тестов и стоит возвращать его к дефолтному состоянию после каждого. Теперь создадим правило, которое будет проводить все подготовки к тестированию фрагмента описанные выше. Перед каждым тестом будет разблокирован экран, запущено активити, открыт нужный нам фрагмент и установлен тестовый Dagger компонент, предоставляющий моки зависимостей.

Установим тестовый компонент в тесте нашего фрагмента:

Тесты запускаемые только для Debug приложения

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

Эту логику тоже нужно тестировать, но тесты должны запускаться только при соответствующем типе сборки приложения. Напишем правило DebugTestRule , которое будет проверять тип сборки приложения и запускать тесты только для дебаг версии:

Тест с этим правилом будет выглядеть следующим образом:

Заключение

В этой статье мы разобрались с базовыми библиотеками для написания тестов и разработали набор инструментов, основанных на TestRule и предназначенных для решения проблем запуска активити и фрагментов, работой с асинхронным кодом, даггером, отладочным кодом и эмулятором андроида. Применение этих инструментов позволило протестировать неочевидные проблемы, снизить дублирование кода и в целом повысить читабельность тестов.

Полный пример приложения и тестов, использующих все вышеперечисленные библиотеки и утилиты.

Источник