Тестирование приложения
Немного поработав в 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.
Источник
Урок 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 разработчиком, то вам имеет смысл изучить эту тему. При устройстве на работу начального/среднего уровня, знание тестирования будет вам очень большим плюсом. А если претендуете на серьезную позицию, то без умения писать тесты никак не обойтись.
В этом уроке я рассмотрел самые простейшие тесты и инструменты. В следующих уроках я планирую подробно рассмотреть возможности различных инструментов тестирования. Не знаю пока сколько будет уроков. Но, думаю, что не меньше десяти для начала.
Источник
