Build test 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 модуля приложения имеется строка для компиляции юнит-тестов.

UI Testing

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

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

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

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

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

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

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

Источник

Тестирование на Android: Robolectric + Jenkins + JaСoСo

Тестирование Android приложений — тема большая и емкая, говорить о ней можно бесконечно. Мы в Rambler&Co автотесты любим, пишем и активно используем для всех наших приложений. В данной статье мы расскажем, как получать и анализировать результаты тестирования android (и не только) приложений. Покажем как настроить Robolectric, JaCoCo и Jenkins, чтобы было вот так:

Robolectric

Robolectric — это библиотека, которая позволяет запускать тесты для android-приложений на локальной JVM. Да, да, именно так, не нужно ждать пока загрузится и установится apk, пока запустится приложение на телефоне, просто нажимаете запустить и JVM быстро прокручивает все тесты. Android среда эмулируется, есть доступ к основным функциям.

Robolectric активно развивается, но в ней все еще есть множество проблем, поэтому мы используем robolectric для тестирования бизнес объектов, логики приложения, хранения и обработки данных. Там, где чистого jUnit уже мало, а реальный девайс все еще не нужен. Для ui тестирования мы рекомендуем Espresso от Google.
В сети достаточно мало материалов про эту замечательную библиотеку на русском языке, поэтому приложим небольшую инструкцию по настройке.

Установка

С выходом версии 3.0 установка библиотеки умещается в одну строчку (раньше требовался еще и плагин), добавить в dependencies:

Обратите внимание, что мы указали testCompile, а не androidTestCompile. testCompile указывает, что данные зависимости нужны для Unit Tests, а androidTestCompile – для Android Instrumentation Test. Выбираем в окошке build Variants, Test Artifact — Android Instrumentation Test, ждем, пока обновится студия, и вуаля… тесты пропали! Что же делать?

Дело в том, что для unit тестов (по умолчанию) используется src/test, а для android test — src/androidTest. Создаем в папке src\ следующие папки: \test\java и \test\resources. Первая используется для тестов, вторая для ресурсов. Вот пример доступ к ресурсам:

Первый тест

Писать тесты под robolectric очень просто: создаем тесты, пишем код, используем аннотации. Доступ к активити через setupActivity\buildActivity. Более подробно со всеми особенностями можно ознакомиться на сайте, robolectric.org/writing-a-test

Запуск тестов

И получаем результат в run – окошке:

Запуск всех тестов из консоли:
gradlew test

JaCoCo

Сайт: www.eclemma.org/jacoco
Для добавления библиотеки в android, необходимо обновить ваш файл gradle:

Будьте внимательны при указании executionData. Это место хранения exec файла, который содержит все данные о покрытии кода тестами.

Теперь можно проверить работу командой gradlew jacocoTestReport. Отчеты о должны быть в папке: build\reports\tests
Если не запускается, выполните команду:
gradlew clean assemble test jacocoTestReport

Результаты тестов представляются в виде html отчета, скриншоты:

Источник

10 ноября 2016 г. Простые Unit-тесты в Android

Вот и настало время разобраться и написать небольшую заметку о том, что из себя представляет тестирование логики Android-приложений. К этому вопросу я пришел не сразу, однако учиться никогда не поздно!

Общие сведения

Для начала определимся, что такое тесты и зачем их нужно писать. Из Wikipedia:

Модульное тестирование, или юнит-тестирование (англ. unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы.

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

Другими словами, тесты — это методы, которые проверяют работоспособность нашего кода. Но каким образом это делается? Давайте по порядку. Тест считается выполненным, если он выполнился без ошибок. А для разного рода проверок используются вспомогательные методы вроде «семейства» методов assertXXX (см. примеры ниже).

Unit-тестирование в Android можно разделить на 2 типа:

• Локальные unit-тесты (Local unit tests) — тесты, для выполнения которых используется только JVM. Они предназначены для тестирования бизнес-логики, которая не взаимодействует с операционной системой.
• Инструментальные unit-тесты (Instrumented unit tests) — тесты, с помощью которых тестируется логика, «завязанная» на Android API. Их выполнение происходит на физическом девайсе/эмуляторе, что занимает значительно больше времени, чем локальные тесты.

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

Также при создании тестов стоит уделить внимание организации пакетов. Существует следующая структура, которой стоит придерживаться:

• app/src/main/java — исходный код приложения;
• app/src/test/java — здесь размещаются локальные тесты;
• app/src/androidTest/java — сюда помещаем инструментальные тесты.

Настройка

Если вы почему-то не используете Android Studio, которая генерирует пакеты при создании проектов, стоит запомнить структуру выше. К тому же, IDE конфигурирует Gradle-файл модуля app:

Для упрощения написания тестов огромной популярностью пользуется фреймворк Mockito. В его возможности входит имитация и наблюдение объектов, а также вспомогательные средства проверок. Чтобы начать его использовать, добавим зависимость:

Local-тесты в Android

Теперь давайте рассмотрим 2 простейших теста, которые проверяют на соответствия 2 объекта (в нашем случае — числа):

Для этого создадим в пакете для локальных тестов класс и разместим в нем наши методы. Чтобы JUnit знал, что эти методы являются тестами, они помечаются соответствующей аннотацией @Test . Метод же assertEquals() кидает ошибку AssertionError в случае, если первый (ожидаемый) и второй (результат) не соответствуют друг другу.

Давайте запустим их (нажав правой кнопкой на класс и выбрав Run ‘ExampleUnitTest’ в появившемся меню) и посмотрим на результат выполнения:

Видно, что первый метод выполнился, а во втором произошла ошибка, т.к. 5 != (2 + 2). Также можно настроить тест на ожидаемое исключение используя параметр expected :

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

Есть еще такой хитрый механизм как Matchers. К примеру, их на вход принимает метод assertThat(T actual, Matcher matcher) и возвращают методы класса org.hamcrest.CoreMatchers . Матчеры представляют собой логические операции совпадения. Рассмотрим несколько из них:

Как видно из названий, is() можно описать как оператор «равно», is(not()) как «неравно», а hasItem() — как проверку на наличие элемента в списке. И читается это как связное предложение. Здесь можно найти весь перечень матчеров.

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

Как упоминалось выше, Mockito используется для создания «заглушек». Они называются mock-объектами. Их цель — заменить собой сложные объекты, которые не нужно/невозможно тестировать. Объявить их можно двумя способами:

Обратите внимание, что для того, чтобы использовать аннотацию @Mock , класс нужно пометить аннотацией @RunWith(MockitoJUnitRunner.class) или вызвать MockitoAnnotations.initMocks(this); в @Before -методе:

Получив «замоканный» объект, можно творить настоящие чудеса! К примеру, для того, чтобы «переопределить» название приложения из строкового ресурса, можно сделать следующее:

Теперь при вызове метода getString() будет возвращаться «Fake string», даже если он вызван неявно (за пределами теста):

Но что если мы хотим переопределить все строковые ресурсы? Неужели нам придется прописывать эту конструкцию для каждого из них? Естественно, нет. Для этого предусмотрены методы anyXXX() , (anyInt() , anyString() , etc. Теперь, если заменить R.string.app_name на anyInt() (не забываем, что в Android все ресурсы имеют тип Integer) — все строки будут заменены на нашу строку.

А убедиться в этом мы можем, дописав assertThat() в конце нашего теста:

В случае, когда мы хотим выбросить Exception, можно использовать конструкцию when(. ).thenThrow(. ); .

Есть еще магический метод verify() который провалит тест в случае, если указанный метод не был до этого вызван. Взглянем на код:

Работает это так: мы передаем в verify(mockedList) наш мок-лист, после чего указываем, какие именно методы нас интересуют. В данном случае добавление строки и очистка списка. Неотъемлемый инструмент, как по мне 🙂

Но по-настоящему потенциал этого метода раскрывается при использовании spy-объектов. Их главное отличие в том, что они не создаются напрямую, в отличие от mock’ов. А толку-то с них, спросите вы? А толк в том, что создав «шпиона» вы можете следить за ним также, как и за фейковым объектом:

Instrumented тесты в Android

При помощи этого типа тестов мы получаем доступ к реальному контексту, а также ко всем возможностям Android API. Помимо этого, у нас есть «режим Бога», при помощи которого мы можем управлять жизненным циклом активности. Для того, чтобы тест распознавался как инструментальный, нам нужно пометить класс соответствующей аннотацией:

Сами же тесты мы помечаем так же, как и в случае локальных — при помощи аннотации @Test . Давайте проверим, соответствует ли пакет нашего контекста нашему приложению:

С помощью имеющегося инструментария можно прослушивать состояние активностей:

. или и вовсе управлять их состоянием:

Заключение

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

Источник

Тестирование 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 и предназначенных для решения проблем запуска активити и фрагментов, работой с асинхронным кодом, даггером, отладочным кодом и эмулятором андроида. Применение этих инструментов позволило протестировать неочевидные проблемы, снизить дублирование кода и в целом повысить читабельность тестов.

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

Источник