Создать свой тест для андроид

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

Источник

Инструменты разработчика для тестирования Android-приложений

В командной разработке тесты – это, как правило, задача QA- и SDET-специалистов. Вместе с тем навыки тестирования полезны и разработчикам, позволяя им проверить свои приложения и повысить стабильность их работы.

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

На примере Android-разработки обсудим подходящие инструменты тестирования – от JUnit до Kaspresso, а также немного познакомимся с методологиями Test Driven Development (TDD) и Behaviour Driven Development (BDD). Наконец, рассмотрим их отличия на примере кейса.

Тестирование IT-системы охватывает множество проверок архитектуры, UI, кода и взаимодействия его частей, соответствия требованиям. По мере усложнения систем в отрасли растут потребности как в обеспечении качества (QA), так и в автоматизации тестирования (SDET), которая позволяет проводить некоторые тесты быстро и с минимальным участием людей.

Уровни тестирования

С появлением тестов для различных уровней программы возникла их абстрактная иерархия – Пирамида автотестов, в которую входят:

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

Интеграционные тесты. Проверяют логику взаимодействия различных компонентов, подсистем без использования UI. В контексте Android сюда входят тесты БД (миграции, выборки, CRUD операции), тесты api-сервисов с моковыми данными и т.д.

UI-тесты. В контексте Android это полноценное автоматизированное тестирование экрана или набора экранов, проверка корректной работы пользовательского интерфейса. Вся логика при этом должна быть протестирована на нижних уровнях.

https://qastart.by/mainterms/64-piramida-testov-testirovaniya

При выборе необходимых проверок, помимо пирамиды, можно использовать колесо автоматизации – подробнее об этом читайте здесь.

Рассмотрим инструменты, используемые на каждом из вышеупомянутых уровней.

Unit-тесты

Unit-тесты – это самый простой инструмент для вовлечения разработчика в процесс тестирования приложения. Они фокусируются на конкретном классе или участке кода и пишутся непосредственно разработчиками. Unit-тесты должны выполняться быстро и иметь однозначные результаты: правильно написанные тесты – отличный способ немедленной проверки произведенных изменений в коде. Также функционал Android Studio позволяет выполнять не весь набор тестов, а только те, которые необходимы разработчику для проверки. Помимо этого, unit-тесты – один из вариантов документации кода для разработчиков, они помогают увидеть, какие возможные результаты имеет метод и какие граничные случаи он обрабатывает.

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

Unit-тесты для Android по умолчанию располагаются в папке src/test проекта или модуля, запускаются с использованием фреймворка JUnit. В идеале, один тест должен тестировать открытый интерфейс одного класса и проверять все ветвления кода и граничные случаи в нем. Зависимости должны иметь поведение, необходимое для проверки тестируемого класса.

В современных Android приложениях для unit-тестов, в основном, используются следующие библиотеки:

JUnit. Для запуска тестов, вызова assertion’ов.

Mockk. Позволяет мокать final классы Котлина, suspend функции, имеет удобный DSL для работы.

kotlinx-coroutines-test. Тестирование suspend-функций внутри TestCoroutineScope, предоставляемого функцией runBlockingTest, подмены main dispatcher’а в рамках тестов.

turbine. Небольшая, но удобная библиотека для тестирования kotlinx.coroutines.Flow.

robolectric. Позволяет писать unit-тесты для классов, использующих Android SDK без непосредственного запуска устройства – фреймворк умеет симулировать различные части системы.

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

Эти тесты для Android по умолчанию располагаются в папке src/androidTest проекта или модуля и запускаются уже на устройстве, так как должны иметь доступ, например, к контексту приложения для создания БД Room. Для запуска тестов используется уже упомянутый фреймворк JUnit.

Инструменты для тестирования пользовательского интерфейса

UI-тесты служат, в основном, для прогона основных пользовательских сценариев приложения (авторизация, регистрация, добавление товара в корзину и т.п.). Они помогают отловить ошибки в базовых сценариях и исправить их до попадания сборки с багами к тестировщикам. UI-тесты также по умолчанию располагаются в папке src/androidTest и запускаются на устройстве. Помимо JUnit, основные инструменты – это:

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

UI Automator. В отличие от Espresso, позволяет взаимодействовать с другими приложениями: совершать звонки, отправлять сообщения, изменять настройки устройства.

Kaspresso. Обертка над Espresso и UI Automator, которая позволяет писать стабильные, быстрые, удобочитаемые тесты.

Для тестирования интерфейсов, реализованных с помощью Jetpack Compose, также появляются свои библиотеки, например, эта.

Также на Хабре можно прочитать больше об инструментах для UI-тестирования, например, в этой статье.

TDD и BDD

TDD и BDD – две популярные методики разработки через тестирование. Рассмотрим их отличия на примере следующего кейса:

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

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

TDD (Test Driven Development) – это методология разработки ПО, основанная на следующих коротких циклах:

Написать тест, проверяющий желаемое поведение.

Запустить тест. Test failed.

Написать программный код, реализующий требуемое поведение.

Запустить тест. Test succeeded.

Провести рефакторинг написанного программного кода, сопровождая прогонами теста.

Для начала создадим контракт нашей реализации.

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

Запускаем тест, получаем ожидаемый результат:

Теперь напишем реализацию

Запустим тесты: все 4 теста проходят. Теперь настало время рефакторинга написанного кода.

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

Методология TDD имеет следующие преимущества:

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

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

Позволяет локализовать ошибки быстрее.

В числе минусов можно выделить следующие:

Фокусировка на реализации задачи.

Код и описание тестов пишутся на одном языке.

В процесс вовлечена только команда разработки.

Подробнее про данную методологию можно прочитать в книге Кента Бека Экстремальное программирование. Разработка через тестирование.

BDD (Behaviour driven development) – методология разработки ПО, во многом схожая с TDD. Отличается тем, что тестовые сценарии пишутся на “человеческом” языке, а не на языке программирования.

Тестовые сценарии записываются в формате given-when-then. Например, given (имея) подключение к сети, when (когда) пользователь открывает ссылку, then (тогда) контент страницы отображается.

Перепишем наши требования с использованием BDD:

Сценарий: добавление траты.

Given Корректную сумму

And Введенный комментарий

And Выбранную категорию траты

When Пользователь нажимает кнопку добавления

Then Пользователь получает успешный результат

Для данного подхода существуют свои фреймворки. Например, для Java это фреймворк JBehave.

К особенностям данного подхода можно отнести следующее:

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

Тестовые сценарии легко изменяются.

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

Узнать подробнее о BDD можно в этой статье.

Заключение

Мало у кого возникают сомнения, что тесты необходимы для проектирования качественного ПО. Существует множество фреймворков, инструментов и методологий (DDD, FDD и другие *DD), которые помогают команде на всех этапах жизненного цикла ПО. Тесты помогают быстро найти и локализовать ошибки, а также, если они правильно спроектированы, могут служить тестовой документацией. Также благодаря тестам код реализации, скорее всего, будет написан чище и понятнее. В то же время главное – не 100% покрытие кода тестами, а его соответствие бизнес-задачам, поэтому важно избегать крайностей и не писать тесты ради тестов.

Спасибо за внимание! Надеемся, что этот материал был вам полезен.

Источник