Тестирование Android приложений
Введение
Я уверен, что современных программистов не нужно убеждать использовать юнит тесты. И если при разработке приложений под android, модули не связанные с ним, мы можем протестировать с помощью знакомого всем JUnit’а (не всегда без костылей правда), то как тестировать user interface и использующие его классы? В этом нам помогут инструменты фреймворка android.test.
В данной статье мы напишем небольшое android приложение и протестируем его. Для работы нам будут нужны установленные jdk, android sdk, Eclipse и ADT плагин.
Часть первая. SpeedConverter.
Наше примитивное приложение будет переводить «километры в час» в «метры в секунду» и наоборот, а также выдавать сообщение Error!, если нужное значение не удается вычислить. Пользователь будет вводить данные о скорости в любой EditText и в другом получать результат. Более подробно на нем останавливаться не будем.
XML layout формы:
xml version =«1.0» encoding =«utf-8» ? >
LinearLayout xmlns:android =«schemas.android.com/apk/res/android»
android:orientation =«vertical»
android:layout_width =«fill_parent»
android:layout_height =«fill_parent»
android:padding =«12dp» >
TextView
android:id =»@+id/textKmPerHour»
android:text =»@string/kmh»
android:layout_width =«wrap_content»
android:layout_height =«wrap_content»/>
EditText
android:id =»@+id/editKmPerHour»
android:layout_height =«wrap_content»
android:layout_width =«match_parent»
android:inputType =«numberDecimal»
android:numeric =«decimal»/>
TextView
android:id =»@+id/textMetersPerSec»
android:text =»@string/ms»
android:layout_width =«wrap_content»
android:layout_height =«wrap_content»
android:paddingTop =«4dp»/>
EditText
android:id =»@+id/editMetersPerSec»
android:layout_height =«wrap_content»
android:layout_width =«match_parent»
android:inputType =«numberDecimal»
android:numeric =«decimal»/>
LinearLayout >* This source code was highlighted with Source Code Highlighter .
Далее устанавливаем listener для Kilometers per hour EditText’а и при наступлении события вычисляем скорость. Нюанс, что onKey() не наступает при активной software клавиатуре мы учтем позже в тестах. Второй EditText работает по аналогии.
// setup listener for Kilometers per hour EditText
editKmPerHour.setOnKeyListener( new OnKeyListener() <
public boolean onKey(View v, int keyCode, KeyEvent event ) <
if ( event .getAction() == KeyEvent.ACTION_UP) <
try <
double kmPerHour = Double.parseDouble(editKmPerHour
.getText().toString());
double meterPerSec = kmPerHour * 0.2777777777777778;
editMeterPerSec.setText( new Double(meterPerSec)
.toString());
> catch (NumberFormatException e) <
editMeterPerSec.setText(R. string .errorMsg);
Log.d(LOG, «e:» + e);
>
return true ;
>
return false ;
>
>);* This source code was highlighted with Source Code Highlighter .
Теперь перейдем к тестированию.
Часть вторая. SpeedConverterTest.
Android Test Project
В первой части мы создали приложение SpeedConverter. Сейчас для него нам нужно создать новое тестовое приложение. Идем в меню eclipse’a: File -> New -> Projects. в появившемся окне выбираем Android -> Android Test Project, нажимаем Next и видим такое окно:
Зададим следующие значения:
- Test Project Name: SpeedConverterTest
- Test Target: устанавливаем «An existing Android project» и выбираем наше проект SpeedConverter
- Application name и Package name подставятся автоматически
И кликаем Finish.
Создание Test Case класса
В директории src/ нашего проекта мы создадим новый класс New > Class. Назовем его SpeedConverterTest и в качестве SuperClass’а укажем android.test.ActivityInstrumentationTestCase2. Наш диалог будет выглядеть так:
Теперь немного подробней об ActivityInstrumentationTestCase2. Данный класс спроектирован для тестирования activities в android приложении. Он может создавать activity (используя InstrumentationTestCase.launchActivity()), запускать тесты в UI thread и позволяет посылать нам различные mock Intents в нашу activity. В качастве параметра мы должны будем передать SpeedConverter.
Добавим test case конструктор который будет использоваться тестирующим фреймворком. В качестве параметров мы покажем какое android приложение будет тестироваться.
public SpeedConverterTest() <
super( «com.pyjioh» , SpeedConverter. class );
>
Далее, знакомый по JUnit’у метод setUp(), который вызывается перед запуском тестов, будем инициализировать в нем переменные.
@Override
protected void setUp() throws Exception <
// TODO Auto-generated method stub
super.setUp();
activity = getActivity();
editKmPerHour = (EditText) activity
.findViewById(com.pyjioh.R.id.editKmPerHour);
editMeterPerSec = (EditText) activity
.findViewById(com.pyjioh.R.id.editMetersPerSec);
>
Начинаем добавлять тесты, они будут простыми дабы показать как взаимодействовать с UI, первый будет проверять — создалась и запустилась ли наша SpeedConverter activity, а также имеем ли мы доступ к нашим контролам.
public void testControlsCreated() <
assertNotNull(activity);
assertNotNull(editKmPerHour);
assertNotNull(editMeterPerSec);
>
Используя метод assertOnScreen() из ViewAsserts проверяем видны ли наши контролы.
public void testControlsVisible() <
ViewAsserts.assertOnScreen(editKmPerHour.getRootView(), editMeterPerSec);
ViewAsserts.assertOnScreen(editMeterPerSec.getRootView(), editKmPerHour);
>
Запускается ли приложение с пустыми EditText’ми.
public void testStartingEmpty() <
assertEquals( «editKmPerHour is not empty» , «» , editKmPerHour.getText()
.toString());
assertEquals( «editMeterPerSec is not empty» , «» , editMeterPerSec
.getText().toString());
>
Теперь добавим тест, проверяющий правильность перевода км/с в м/с. В нем мы используем TouchUtils.tapView(..) который симулирует касание по нужному нам контролу, а KeyEvent.KEYCODE_BACK убирает software клавиатуру. Метод void testConvertMsToKmh() выглядит аналогично.
public void testConvertKmhToMs() <
TouchUtils.tapView( this , editKmPerHour);
sendKeys(KeyEvent.KEYCODE_BACK, KeyEvent.KEYCODE_1, KeyEvent.KEYCODE_0,
KeyEvent.KEYCODE_0);
double meterPerSec;
try <
meterPerSec = Double.parseDouble(editMeterPerSec.getText()
.toString());
> catch (Exception e) <
meterPerSec = -1;
>
assertTrue( «100 km/h is not 27.778 m/s» , meterPerSec > 27.7
&& meterPerSec
Последний тест проверяет — получаем ли мы сообщение об ошибке.
public void testGetError() <
TouchUtils.tapView( this , editKmPerHour);
sendKeys(KeyEvent.KEYCODE_1, KeyEvent.KEYCODE_DEL);
assertEquals( «Must be Error!» ,
activity.getString(com.pyjioh.R. string .errorMsg),
editMeterPerSec.getText().toString());
>
Запустим наше тестовое приложение: Run As > Android JUnit Test. На видео ниже показано как это будет выглядеть.
Таким образом, мы протестировали функционал нашего несерьезного приложения.
Источник
Урок 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 разработчиком, то вам имеет смысл изучить эту тему. При устройстве на работу начального/среднего уровня, знание тестирования будет вам очень большим плюсом. А если претендуете на серьезную позицию, то без умения писать тесты никак не обойтись.
В этом уроке я рассмотрел самые простейшие тесты и инструменты. В следующих уроках я планирую подробно рассмотреть возможности различных инструментов тестирования. Не знаю пока сколько будет уроков. Но, думаю, что не меньше десяти для начала.
Источник
