пятница, 13 февраля 2015 г.

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

Итак.

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





Gradle

Как я уже писал с переходом на Android Studio, по умолчанию в новых проектам включена система сборки gradle. Я не знаю всех ее преимуществ, но то, что ее можно гибко настроить под различные задачи это факт. Например, вот так:

    compile 'com.android.support:support-annotations:21.0.3'
    androidTestCompile ('com.android.support.test.espresso:espresso-core:2.0')

Во первых, для того чтобы подключить нужную библиотеку, нужно всего лишь знать ее название\имя пакета в глобальном репозитории и подключить в Ваш проект. Прямо как в Linux! Информацию о той или иной библиотеке можно получить как на сайте\гитхабе разработчика так и на сайте gradle, please

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

JUnit

Следующим шагом я решил разобраться с JUnit. В предыдущем учебном семестре я уже немного познакомился с JUnit. Тогда тестированию с моей стороны подверглись несколько простых консольных приложения на Java. На тот момент, запустить тесты на Android у меня не получилось. Почему? Об этом немного ниже.

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

Только сейчас я я подошел к вопросу более сознательно и уже могу ответить на некоторые вопросы, как же все там устроено!)

Для нового приложения Android Studio автоматически создает папку для тестов.


Также, в Android Studio  прямо из коробки уже идет поддержка JUnit. В классе унаследованном от TestCase пишем тесты и все работает. Но кроме TestCase есть еще AndroidTestCase и InstrumentationTestCase. Оба в свою очередь расширяют TestCase, и подходят для тестов, в которые никак не обойтись без Android Contex.

Для еще больше ясности приведу еще цитату:

You can use the JUnit TestCase class to do unit testing on a class that doesn't call Android APIs. TestCase is also the base class for AndroidTestCase, which you can use to test Android-dependent objects. Besides providing the JUnit framework, AndroidTestCase offers Android-specific setup, teardown, and helper methods.

Но и это еще не всею если подключать androidTestCompile('junit:junit:4.12'), то можно писать тесты без расширения TestCase, вместо этого использовать аннотации @Test и другие.

Все выше описанные способы тестирование не запускают Activity. поэтому переходим дальше. 


Espresso

Функциональные тесты это конечно и смотреть на красно зеленые лампочки тоже интересно, но куда прикольнее смотреть на магию на экране во время запуска UI тестов. Для этого в Android тоже есть стандартные средства. Расширяем ActivityInstrumentationTestCase2 получает доступ к Activity и в бой. Но это жутко не удобно (как для меня)! Поэтому я пошел по стороннему пути и научился пользоваться  Espresso. 

Как утверждают авторы, Espresso это быстрый и легкий фреймворк, который позволяет тестировать UI.

Пример теста:

        onView(withId(R.id.edit)).perform(typeText(""));
        onView(withId(R.id.btn)).perform(click());
        onView(withId(R.id.edit)).check(matches(withText("!!!")));

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

Далее запускаем и наблюдаем магию: экран оживает, кнопки нажимаются, текста набирается, отчет на экране отображается! Немного позже будет видео. 

Немного технических подробностей: 

В файлик конфигурации gradle нужно добавить:

 androidTestCompile ('com.android.support.test.espresso:espresso-core:2.0'){
        exclude group: 'junit'
 }
 androidTestCompile('com.android.support.test:testing-support-lib:0.1') {
        exclude group: 'junit' 
 }

Далее унаследовать класс с тестами от ActivityInstrumentationTestCase2;

Spoon

Следующим список моих инструментов пополнил Spoon. Это утилита для запуска всех вышеописанных тестов сразу на нескольких подключенных реальных\виртуальных устройствах. 

Для лучшего понимания просто стоит посмотреть видео:



Магия да и только!

После запуска тестов на всех подключенных устройствах получаем красивый и полезный отчет с дополнительный информацией по каждому тесту и устройству:


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

Genymotion

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

На данный момент, я создал 5 различных устройств с различными конфигурациями. 



Всем хорошего настроения и творческих успехов!








2 комментария:

  1. Привет.

    Когда-то ты оставил коммент в моем блоге. Прошло много времени, я не занимался своими проектами. Но вот решил зайти на блок, а по твоей ссылке попал сюда.

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

    ТО есть строчки вида

    :andengine:transformResourcesWithMergeJavaResForRelease UP-TO-DATE

    Как отключить эту проверку при каждом тесте? Это же не оптимально - после каждого исправления в коде всё перепроверять...

    ОтветитьУдалить
  2. я пока не пишу тесты, которые нужно запускать на физическом устройстве) Robolectric вполне хватает.

    ОтветитьУдалить