Android studio модульное тестирование

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

Немного поработав в 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 Studio

В предыдущей статье мы объяснили набор проблем в веб-просмотре, объяснили оптимизацию производительности веб-просмотра, информацию cookie веб-просмотра, очистку ошибки информации веб-просмотра при выходе из активности, как взаимодействовать друг с другом с помощью кода Java и кода js, как веб-просмотр загружает файлы и Служба просмотра Tencent X5 и другие знания — это проблемы, трудности, практики и т. Д., С которыми я столкнулся при использовании webview. Для получения дополнительных инструкций по этим проблемам обратитесь к моей:Разработка продуктов Android (18) -> яма веб-просмотра

В этой статье мы объясним, как выполнить модульное тестирование в Android Studio. В проектах разработки Android часто выполняются тестовые операции, и запуск эмулятора снова и снова тратит много времени и снижает эффективность работы.Хотя последняя версия Android Studio предоставляет функцию запуска экземпляра для улучшения компиляции Android Studio. Скорость, но нам все еще нужно понимать функцию модульного тестирования Android studio, которая может легко предоставить нам функциональное тестирование, поэтому, если тестовые данные полезны в проекте, вы можете сначала выполнить модульное тестирование. Если данные можно выводить нормально, Затем выполните его в пользовательском интерфейсе, что повысит эффективность работы.

Что такое модульный тест:

Прежде чем объяснять, как выполнять модульное тестирование в Android studio, давайте популяризируем базовые знания, то есть, что такое модульное тестирование. Здесь я процитирую описание модульного тестирования в Энциклопедии:

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

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

Какова роль модульного тестирования:

Тестирование в Android обычно делится на: функциональное тестирование, тестирование пользовательского интерфейса, модульное тестирование и т. Д .;
Поскольку приложению требуется среда выполнения Android, а наши модульные тесты Android обычно не могут предоставить среду выполнения, обычно функциональные тесты, тесты пользовательского интерфейса и т. д. необходимо выполнять на симуляторе или на реальной машине. , Но некоторые функциональные требования не требуют функций среды Android. Если вы также используете Android studio для перекомпиляции и запуска, это займет слишком много времени. Вообще говоря, компиляция, установка и запуск файла apk занимает минуту или две. Как правило, можно провести три или четыре минуты, поэтому для тестирования простой функции требуется много времени на перекомпиляцию и запуск, а производительность слишком низкая.

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

Поддержка Android Studio для модульного тестирования:

В новой версии Android studio добавлена ​​поддержка модульного тестирования; как показано на рисунке:

Просто напишите тестовые примеры в этом каталоге.

Что может тестировать модульное тестирование?

Здесь необходимо объяснить, что модульный тест студии Android только моделирует среду разработки Android, но это не настоящая среда разработки Android, поэтому он не может тестировать функции пользовательского интерфейса, не может тестировать функции, требующие аппаратной поддержки (например, Bluetooth, Wi-Fi и т. Д.), И не может тестировать приложение. Прыгать и так далее, так что это может проверить?

Протестируйте некоторые функции данных, например загрузку сетевых данных.

Тестируйте SharedPerferences, тестовые базы данных, тестовые функции и т. Д.

Инструментальное тестирование, такое как время проверки, формат преобразования, регулярная проверка и т. Д.

Простой пример модульного теста:

Давайте посмотрим на написание тестовых примеров:

Это класс модульного теста по умолчанию, созданный проектом. Видно, что он не сильно отличается от обычного класса Class. Он просто вызывает соответствующий тестовый API. Затем мы настроим наш собственный класс модульного теста.

Напишите собственный класс тестового случая:

• Реализовать метод тестового примера

Класс тестового примера должен использовать аннотации: @MediumTest и @RunWith (AndroidJUnit4.class)

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

Например, если мы удалим аннотацию Test:

Если вы запустите его снова, исполняемая функция тестирования не будет найдена.

Есть еще одна проблема. Мы можем обнаружить, что все наши функции являются общедоступными. Что, если мы сделаем нашу тестовую функцию частной? Измените функцию тестирования

После казни вы можете найти:

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

Функция тестирования должна быть общедоступной

Тестовая функция должна добавить аннотацию @Test

Как выполнять тестовые примеры

• Щелкните правой кнопкой мыши, чтобы выполнить прямо в исходном коде

После написания как запустить?

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

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

Например: приложение, контекст и т.д .; будет ли удобно, когда мы снова будем писать модульные тесты в будущем?

• Выполнить тестовые примеры в меню студии Android

－Выбрать запустить － изменить конфигурацию

-Добавить варианты использования тестов Android

-Настроить метод тестирования

Нажмите ОК, в этот раз только что добавленный тестовый пример появится в области выполнения.

Небольшой пример простого модульного теста:

Сказав это, давайте приведем пример развития силы.

ситуация
Есть ситуация, когда нам нужно использовать регулярные выражения для проверки строки во время процесса разработки, но мы хотим проверить это регулярное выражение перед перекомпиляцией Apk и запустить проект напрямую. Играть тоже можно, но слишком медленно. Есть какой-нибудь простой способ проверить? На данный момент мы можем использовать наш модульный тест.

• выполненный
  

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

подводить итоги:

Итак, после ряда операций, мы ввели этапы модульного тестирования в Android Studio. Как насчет? Очень просто, О (∩_∩) О хаха

Android studio по умолчанию поддерживает модульное тестирование, вы можете писать тестовые случаи под AndroidTest в модуле

API для получения контекста предоставляется в тестовом примере, и объект контекста можно получить с помощью этого метода.

Метод тестового примера должен использовать аннотацию @Test для указания, иначе будет сообщено об ошибке и метод тестирования не может быть найден.

Метод тестирования должен быть определен как общедоступный, иначе будет сообщено об ошибке.

Есть два способа выполнить метод тестирования: вы можете выполнить его напрямую в исходном коде или настроить метод тестирования в Android Studio.

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

Источник

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, рекомендую почитать официальную документацию, а вот материал про возможности инструментальных тестов.

Источник