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?

Просто скачан Android Studio, основанный на идее Intellij Idea.

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

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

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

Есть ли у кого-нибудь опыт?

ОТВЕТЫ

Ответ 1

Изменить: с 0.1.8 это теперь поддерживается в среде IDE. Пожалуйста, следуйте инструкциям там, вместо использования нижеприведенных инструкций.

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

• Добавить каталог src/instrumentTest/java для тестов
• Добавить тестовый класс (расширяющий ActivityTestCase) в пакете com.example.myapplication.test
• Запустить виртуальное устройство
• В командной строке (в каталоге MyApplicationProject/MyApplication) используйте команду «../gradlew connectedInstrumentTest»

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

Ответ 4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Снова нажмите одну из этих зеленых кнопок.

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

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

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

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

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

Затем нажмите Запустить > Записать эспрессо-тест в меню.

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

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

Дальнейшее исследование

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

• Создайте папку, в которой вы будете писать все ваши модульные тесты (желательно com.example.app.tests)
• Создайте новый тестовый класс (желательно NameOfClassTestedTests, например, BankAccountLoginActivityTests)
• Расширить InstrumentationTestCase
• Запишите неудачный unit test, чтобы убедиться, что нам удалось настроить модульные тесты
• Обратите внимание, что имя метода unit test должно начинаться со слова «test» (предпочтительно testTestedMethodNameExpectedResult() i.e testBankAccountValidationFailedShouldLogout())
• Настройте проект для модульных тестов:
• Откройте меню «Выполнить. » и нажмите «Редактировать конфигурации»
• Нажмите кнопку +
• Выберите шаблон Android Tests
• Введите имя для вашей конфигурации запуска (желательно «тесты AppName» )
• Выберите свое приложение в модуле combobox
• Выберите переключатель «Все в пакете» (обычно вы должны выбрать этот вариант, потому что он выполняет все модульные тесты во всех ваших тестовых классах)
• Заполните имя тестового пакета с шага 1 (например, com.example.app.tests)
• Выберите устройство, для которого вы хотите запустить тесты.
• Применить и сохранить конфигурацию
• Выполнить тесты модулей (и ожидать сбой):
• Выберите новую созданную конфигурацию тестов в меню «Выполнить»
• Нажмите «Выполнить» и прочитайте результаты в выходной консоли.

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

Ответ 9

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

В файле .iml указывается, где разместить тестовые классы.

Ответ 10

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

Ответ 11

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

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

Ответ 12

Android Studio v.2.3.3

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

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

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

Источник

Урок 1. Зачем нужны тесты и как они работают

В этом уроке я расскажу, зачем нужно тестирование, и на простых примерах покажу, как оно работает. Мы рассмотрим три типа тестов: локальные, инструментальные и UI.

Зачем нужно тестирование?

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

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

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

Как работает тестирование?

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

Если вы тестируете приложение Калькулятор, то вы в тесте укажете, что, при использовании чисел 2 и 3, их сумма должна быть равна 5.

Далее вы запускаете тест. Он возьмет заданные вами входные данные (т.е. числа 2 и 3, операция — сумма), использует их в вашем приложении и убедится, что полученный результат совпадает с тем, что вы указали (5).

Кроме этого сценария (2+3=5), вы в тесте пишете проверки и для остальных операций: вычитание, умножение, деление. Например, обязательно надо протестировать попытку деления на 0. Ваше приложение не должно крэшить при выполнении такого теста.

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

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

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

Типы тестов

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

Два EditText, кнопки со стандартными операциями и TextView с результатом.

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

Локальный тест

Этот тест предназначен для тестирования кода, который не зависит от компонентов Android API. Т.е. тестируемый код — это чистый Java код, который ничего не знает про Activity, Fragment, Context и пр., поэтому для запуска не нужен Android-эмулятор или реальное устройство. Локальные тесты запускаются прямо на вашем компьютере, используя Java-машину.

В приложении Калькулятор есть класс Calculator, который выполняет вычисления:

Для упрощения, используем int в качестве типа чисел.

Как видите, это чистый Java код. В нем нет ничего от Android. А значит мы можем создать локальный тест, который будет для нас тестировать этот класс.

Подробный код теста выглядит примерно так:

Сначала создаем экземпляр класса Calculator. На нем будем проводить тест

В переменную actual помещаем результат работы объекта calculator, который сложит два числа: 1 и 2.

В переменную expected пишем ожидаемый результат, который должен получиться при сложении чисел 1 и 2, если calculator работает правильно. 1 + 2 должно быть равно 3.

И методом assertEquals сравниваем ожидаемый результат и то, что вернет нам calculator. Если значения окажутся не равны, то при запуске теста метод assertEquals выбросит ошибку.

Т.е. мы знаем как должен сработать calculator, и мы сверяем это с тем, как он действительно сработал. Результаты должны совпадать. Calculator должен работать так, как мы ожидаем.

Переменные actual и expected я использовал только для наглядности. Тот же тест можно записать так:

Класс теста будет выглядеть так:

Метод addition имеет аннотацию @Test. Это означает, что метод является тестовым и он будет вызван при запуске тестирования. Этот метод тестирует, как работает метод Calculator.add(). Название тестового метода может быть любым, я назвал его addition (сложение), т.к. в нем тестируется операция сложения.

Обратите внимание, я вынес создание объекта сalculator в метод setUp. Этот метод имеет аннотацию @Before, которая означает, что этот метод будет выполнен перед выполнением каждого @Test метода. Это избавляет нас от необходимости самим создавать экземпляр calculator в каждом @Test методе.

Т.е. перед выполнением addition будет выполнен setUp, который создаст экземпляр calculator, и addition использует этот экземпляр.

Запустив этот тест, мы получим сообщение о том, что тест успешно пройден

Т.е. тест выполнил метод add с значениями 1 и 2, получил 3, сравнил это с ожидаемым значением (3) и выяснил, что результат совпал с ожиданием. Значит программа работает так, как мы от нее ожидали.

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

Если сейчас открыть Calculator и поломать там операцию сложения, поменяв плюс на минус

то при запуске тест покажет следующее

Тест сообщает, что ожидалось значение 3, а результат получился -1. Т.е. calculator сработал не так, как мы ожидали, а это означает, что в нем появилась ошибка.

Кроме метода addition, мы можем в тестовом классе создать и другие @Test методы для тестирования остальных операций (вычитание, умножение, деление). А можем создать общий метод, который будет тестировать все операции.

Назовем его operations.

Тестируем все 4 операции разными значениями. А операцию divide тестируем делением на 0. Это случай, который потенциально может привести к непредсказуемому результату или крэшу, поэтому его надо обязательно проверять в тестах.

Результат запуска будет таким

Во всех assert-методах результат совпал с ожиданием. Все ок.

Также в лог вывелось сообщение, что была попытка выполнить деление на 0. Это наше сообщение, мы выводим его в методе Calculator.divide просто для информации.

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

В целом все осталось так, как и было, но был забыт return 0. Если теперь передать в метод b = 0, то в лог уйдет сообщение о том, что была попытка деления на 0, но выполнение метода пойдет дальше и будет крэш.

Тест поймал ошибку, потому что мы в методе operations тестировали сценарий с делением на 0.

Мы предполагали, что деление на 0 может быть опасным и его надо обязательно включить в тесты. И мы не ошиблись. Тест вызвал метод calculator.divide с аргументами 5 и 0, получил крэш и сообщил нам об этом.

Если закомментировать строку проверки деления на 0 в методе operations

и запустить тест, то он вам напишет, что все ок.

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

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

Т.е. понятно, что нет смысла писать тесты типа:

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

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

Инструментальный тест

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

В этом случае, уже не получится запустить тест локально на Java-машине вашего компьютера. Т.е. локальные тесты нам тут не подходят. Нужен Android эмулятор или реальное устройство. Именно на них будут выполняться инструментальные тесты. А значит, в этих тестах мы можем использовать различные Android классы.

Тут необходимо сделать небольшое отступление и сказать, что есть таки возможность писать локальные тесты, которые смогут протестировать объекты, связанные с Android. Но, во-первых, иногда есть необходимость запустить тест именно на Android, а, во-вторых, нам об этом пока рано говорить. Мы эту тему рассмотрим чуть позже. Пока примем как данность, что тесты для объектов, связанных с Android, необходимо запускать на Android.

Для примера снова возьмем Калькулятор. Он хоть и простой, но умеет сохранять данные при закрытии. При выходе из приложения, данные из полей ввода сохраняются в Preferences. А при следующем запуске восстанавливаются обратно.

Для данных используется контейнер Values.

Он хранит два значения и имеет метод для сравнения себя с другим Values.

И есть SaveValuesHelper, который умеет сохранять Values в Preferences и потом читать его оттуда же.

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

Тест может выглядеть так:

Мы используем объект InstrumentationRegistry, чтобы получить Context и создаем абсолютно реальный рабочий объект SharedPreferences, в котором очищаем все данные для чистоты эксперимента. Далее создаем SaveValuesHelper и даем ему для работы SharedPreferences.

Для теста создаем новый объект saveValues с значениями 5 и 2 и просим saveValuesHelper сохранить эти значения в префы. Затем просим saveValuesHelper вытащить значения из префов в readValues. И методом assertTrue проверяем, что метод equalsToValues вернет true. Т.е. те данные, которые мы записали (saveValues) должны быть равны тем значениям, которые мы потом считали (readValues).

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

Запускаем тест и видим, что все ок — тест пройден успешно.

Обратите внимание на кучу текстовой информации. Ее не было в локальных тестах.

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

Давайте сделаем ошибку в программе, чтобы тест выявил ее.

От заказчика поступило требование, что при выходе из приложения надо сохранять в префы не только операнды, но и результат операции. И при открытии приложения восстанавливать.

Не вопрос. Добавляем поле result в Values.

И добавляем сохранение этого result в методе saveValues:

А вот чтение result в методе readValues добавить мы «забываем».

В тесте добавляем тестовое значение 10 для поля Values.result. Остальное не меняется.

Запускаем тест и получаем ошибку

Идем по адресу SaveValuesHelperTest.java:37 и видим там строку:

Метод equalsToValues не вернул true, а значит saveValues и readValues не равны, а значит SaveValuesHelper записал одно (5, 2, 10), а считал другое (5, 2). Идем в SaveValuesHelper и обнаруживаем допущенную ранее ошибку.

UI тест

Третий тип теста вполне можно считать реальным живым QA инженером (тестировщиком). UI тест умеет запускать приложение, вводить в поля значения, нажимать кнопки и т.п. А после этого он может проверить в каком состоянии находятся View на экране, что они отображают и т.п.

Давайте рассмотрим пример такого теста.

Приложение Калькулятор при выполнении какой-либо операции (сложение, вычитание и т.д.), читает значения операндов из полей EditText. После этого он проверяет, что операнды не пусты и в случае, когда хотя бы один пустой, выводит сообщение об этом в то же TextView, куда выводится результат.

В коде это выглядит так

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

В этом тесте мы просим сделать три действия

1) Ввести значение 5 в первый EditText
2) Нажать кнопку сложения
3) Убедиться, что ошибка empty_operands отобразилась в TextView

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

И тест успешно завершается

Давайте и здесь спровоцируем ошибку. Представим, что пришел новый разработчик, не прочитал внимательно тех.задание и решил, что сообщение об ошибке лучше выводить в Toast, а не в TextView.

Вносим изменения в код:

Мы заменили вывод сообщения об ошибке с TextView на Toast.

Запускаем тест и получаем ошибку

android.support.test.espresso.base.DefaultFailureHandler$AssertionFailedWithCauseError: ‘with string from resource id: ‘ doesn’t match the selected view.
Expected: with string from resource id: [empty_operands] value: Empty operands

Что в переводе означает примерно следующее: не обнаружил в указанном вами TextView строку Empty operands. Тест искал сообщение о пустых операндах в TextView, но не нашел, т.к. оно теперь отображается в Toast.

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

Где хранятся тесты?

Вы наверняка обращали внимание на папки Test и AndroidTest, которые создаются у вас в каждом проекте.

Именно в этих папках и хранятся тесты. В папке Test — локальные тесты, а в папке AndroidTest — инструментальные и UI.

Что дальше?

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

От себя могу сказать, что, если вы планируете стать Android разработчиком, то вам имеет смысл изучить эту тему. При устройстве на работу начального/среднего уровня, знание тестирования будет вам очень большим плюсом. А если претендуете на серьезную позицию, то без умения писать тесты никак не обойтись.

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

Источник