Android studio android test что это

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

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

Только что загрузили Android Studio, основанную на Intellij Idea.

Как создать тесты?

Я заметил, что есть опция для создания тестового модуля, но это ничего не делает, только создает новый проект с помощью src

Я также попытался нажать горячую клавишу CTRL + AlT + T, которая позволяет создавать модульные тесты для существующего класса, но, кажется, он хочет поместить его в текущий проект. Конечно, это не помогает с TDD

У кого-нибудь есть опыт здесь?

Этот ответ предназначен для тех, кто только начинает тестирование Android. Я приведу два простых примера, которые помогут вам понять, как работает тестирование. Если вы будете следовать в течение следующих 10 минут, у вас будет все готово, чтобы начать добавлять свои тесты в собственное приложение. Я думаю, вы удивитесь, насколько это просто. Я конечно был.

Введение в Android Тестирование

Есть два разных типа тестов, которые вы будете делать.

• Локальные модульные тесты. Они выполняются локально на JVM (виртуальная машина Java). Так как они местные, они быстрые. Вы можете использовать их для тестирования частей вашего кода, которые просто нуждаются в Java, а не в Android API. (Иногда вы можете создать поддельный объект API для локального тестирования большего количества вещей. Это называется насмешливый . Примером Context является пример.)
• Инструментированные тесты. Эти тесты выполняются на реальном устройстве или в эмуляторе. Это делает их медленнее, чем местные тесты. Однако они более гибкие, поскольку у вас есть полный доступ к API Android.

Создайте новый проект, и вы увидите следующие папки по умолчанию.

Все уже есть и ждут, когда вы создадите свои тесты. Все уже настроено!

Как создать локальные юнит-тесты

Откройте файл ExampleUnitTest , показанный на изображении выше. это должно выглядеть примерно так:

Нажмите двойную зеленую стрелку, чтобы запустить все тесты, или одну зеленую стрелку, чтобы запустить только один. (В этом случае есть только один тест, поэтому они оба делают одно и то же.)

Это должно пройти (пока 2 + 2 все еще 4 , когда вы читаете этот ответ). Поздравляем, вы только что провели первый тест!

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

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

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

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

Как создавать инструментальные тесты

Откройте файл ExampleInstrumentedTest . это должно выглядеть примерно так:

Нажмите одну из этих зеленых кнопок еще раз.

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

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

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

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

Сначала добавьте кнопку в свой интерфейс, чтобы у нас было с чем работать. Я сделал это:

Затем нажмите Run> Record Espresso Test в меню.

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

Большой! Вы только что создали первый инструментальный тест! Это было супер легко. Вы, вероятно, должны добавить утверждение, чтобы сделать его настоящим тестом, но это также довольно легко сделать с рекордером. Смотрите это видео , чтобы пойти немного глубже.

Дальнейшее обучение

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

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

Следуя Руководство пользователя плагина Android Gradle Я смог получить тесты, работающие в командной строке, выполнив следующие шаги для вновь созданного проекта (я использовал стандартный пакет ‘com.example.myapplication’):

1. Добавить каталог src/instrumentTest/Java для тестов
2. Добавьте тестовый класс (расширяющий ActivityTestCase) в пакет com.example.myapplication.test
3. Запустите виртуальное устройство
4. В командной строке (в каталоге MyApplicationProject/MyApplication) используйте команду ‘../gradlew connectedInstrumentTest’

Это запустило мои тесты и поместило результаты теста в MyApplicationProject/MyApplication/build/reports/instrumentTests/connected. Я новичок в тестировании Android приложений, но, похоже, работает нормально.

Из среды IDE можно попробовать запустить тот же тестовый класс. Вам нужно будет

1. Обновите build.gradle, чтобы указать Maven Central в качестве репозитория
2. Обновите build.gradle, добавьте JUnit 3.8 в качестве зависимости toolTestCompile, например, toolTestCompile ‘junit: junit: 3.8’
3. В «Структуре проекта» вручную переместите JUnit, чтобы быть первым в порядке зависимости

Однако это терпит неудачу (путь к классу, используемый при выполнении тестов, отсутствует в каталоге выходных данных теста). Однако я не уверен, что это сработает, независимо от того, насколько я понимаю, что требуется специальный тестировщик Android.

Я бы предложил использовать файл gradle.build.

Добавьте каталог src/androidTest/Java для тестов (Как Крис начинает объяснять)

Откройте файл gradle.build и укажите там:

Нажмите «Синхронизировать проект с файлом Gradle» (на верхней панели). Теперь вы должны увидеть папку «Java» (внутри «androidTest») зеленого цвета.

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

Я думаю этот пост от Rex St John очень полезен для модульного тестирования в студии Android.

Android Studio v.2.3.3

Выделите контекст кода, который вы хотите протестировать, и используйте горячую клавишу: CTRL + SHIFT + T

Используйте диалоговый интерфейс, чтобы завершить настройку.

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

На данный момент (студия 0.61) достаточно поддерживать правильную структуру проекта. Нет необходимости создавать отдельный тестовый проект, как в Eclipse (см. Ниже).

Android Studio продолжает развиваться, поэтому приведенные выше ответы в конечном итоге перестанут применяться. Для текущей версии Android Studio 1.2.1.1 есть хорошее руководство по тестированию:

Похоже, одно из основных изменений заключается в том, что в Android Studio тестовое приложение интегрировано в проект приложения.

Я не уверен, поможет ли это вашей конкретной проблеме, но я нашел руководство по созданию тестов с проектом Gradle. Руководство пользователя Android Gradle

Самый простой способ, который я нашел, — это упорядоченный в мой следующий пост в блоге :

1. Создайте папку, в которую вы будете писать все свои юнит-тесты (предпочтительно com.example.app.tests)
2. Создайте новый тестовый класс (предпочтительно NameOfClassTestedTests, т.е. BankAccountLoginActivityTests)
3. Расширить InstrumentationTestCase
4. Напишите провальный модульный тест, чтобы убедиться, что мы успешно настроили модульные тесты
5. Обратите внимание, что имя метода модульного теста должно начинаться со слова «test» (предпочтительно testTestedMethodNameExpectedResult (), т.е. testBankAccountValidationFailedShouldLogout ())
6. Сконфигурируйте ваш проект для модульных тестов:
7. Откройте меню «Выполнить . » и нажмите «Изменить настройки»
8. Нажмите кнопку +
9. Выберите шаблон Android Тесты
10. Введите имя для своей конфигурации запуска (предпочтительно «Тесты AppName»)
11. Выберите ваше приложение в модуле выпадающего списка
12. Выберите переключатель «Все в пакете» (обычно вы хотите выбрать этот параметр, поскольку он запускает все модульные тесты во всех ваших тестовых классах).
13. Введите имя тестового пакета, начиная с шага 1 (например, com.example.app.tests).
14. Выберите устройство, на котором вы хотите запустить свои тесты
15. Применить и сохранить конфигурацию
16. Запустите юнит-тесты (и ожидайте сбой):
17. Выберите вновь созданную конфигурацию тестов в меню «Выполнить»
18. Нажмите Run и прочитайте результаты в консоли вывода.

Удачи в том, чтобы сделать ваш код более читабельным, поддерживаемым и хорошо протестированным!

Android Studio была своего рода движущейся целью: сначала она представляла собой предварительную версию для разработчиков, а сейчас находится в бета-версии. Путь к классам Test в проекте менялся с течением времени, но независимо от того, какую версию AS вы используете, путь объявляется в вашем файле .iml. В настоящее время с версией 0.8.3 вы найдете следующее во внутреннем IML-файле:

Файл .iml сообщает вам, где разместить тестовые классы.

Начиная с Android Studio 1.1, у нас есть официальная (экспериментальная) поддержка написания модульных тестов (Roboelectric работает также).

Добавьте ниже lib внутри файла gradle

Создайте класс HomeActivityTest в каталоге androidTest и перед запуском теста добавьте строку flurry_api_key и sender_id в строковый файл ресурсов и измените значение для случая неудачи и успеха.

Источник

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

Источник