Приятное тестирование с Espresso

[@VolCh]

Хм. А это точно про юнит-тесты? Больше похоже на функциональные

[@viacheslav_dev]

Про функциональные, уже подправил. В терминалогии иногда путаюсь.

[@Lovesuper]

Друзья, используйте терминологию Google чтобы никогда не путаться. У автора статьи в примерах исходного кода она фигурирует. googletesting.blogspot.ru/2010/12/test-sizes.html

[@zserge]

Что ж они на developer.android.com о ней молчат. А я на днях начал подобный велосипед для тестов делать — bitbucket.org/zserge/lemur
Работает через те же механизмы, что и глючный UI Automator, но намного проще. Тестовые скрипты пишутся на Lua:

lemur.find('./EditText/').text('[e-mail]')
lemur.find('.android.widget.Button', 'Login').click()
assert(lemur.find(./Progress/), 'Progress is not shown')

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

[@viacheslav_dev]

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

[@zserge]

Быстренький grep нашел вот это (ViewMatchersjava):

public static Matcher<View> withId(final Matcher<Integer> integerMatcher) {...} 

Значит умеет по id искать. Внутри как раз view.getId() сравнивается.

[@A_HREF]

На картинке не эспрессо.

[@viacheslav_dev]

Самое главное замечание. Так и знал что нужно было картинку с котиками ставить!

[@Lovesuper]

Дьявол кроется в деталях

[@oxied]

Использовали Robotium. Хорош, но не стабилен. И не сказать, что прям быстр.

Сейчас изучаем новые фреймворки: MonkeyTalk и SOASTA TouchTest.
Моя задача как раз изучить последний, поэтому расскажу о нем немного поподробней.

SOASTA TouchTest.
+ скорость выполнения тестов = скорости нажатий на кнопочки
+ не нужен adb
+ высокая стабильность. полировка практически отсутствует за отсутствием необходимости
+ тестеры вообще могут не копаться в коде, садитесь и пишите как говорится
+ стремящееся к нулю количество необходимых изменений в проекте. перед тестированием запускается специальная утилита, которая сделает все за вас (подправит манифест, добавит билд конфигурации и библиотеки и тп)
+ возможность сборки testable проекта как и из Eclipse, так и средствами Ant

± whitebox testing. по факту не предусмотрено. Но, есть такая вещь как App Internal Value, с помощью которой можно получить необходимое значение чего угодно. Договариваетесь (с самим собой, с командой), за какими «переменными» будет на самом деле выполняться ваш самописный код при обращении к этим переменным и вы решили проблему хоть частично. Например, у нас так осуществляется деавторизация приложения (не через UI же делать)
± не нужно писать код, описывающий тест (исключение — конструкции на js), но и практически невозможно, если появится необходимость (это xml, вспомните ваши build.xml'и, здесь все еще хуже). Пишется исключительно манипуляциями с самим приложением.

[@Ntropy]

Мне одному кажется, что:

Object obj = lvDrawerMenu.getItemAtPosition(2);
onView(withText(obj.toString())).perform(click());

довольно уродливый код?
Брать текст из объекта только что бы найти 2-й элемент в меню, как то дико.
Можно ли решить эту задачу используя только Espresso?

[@busylee]

Спасибо за томик! Есть вопрос, умеет ли Espresso находить View по заданному ресурсу, скажем ImageButton с заданным drawable для него? В данный момент используем Robotium и он к сожалению этого делать не умеет и разработчики ответили что не планируется, к сожалению.

[@viacheslav_dev]

На сколько я помню то не умеет. Я в итоге отказался от использования Espresso в новых проектов. Были заморочки с подключением в АС. Вот сейчас посмотрел то они уже почти год как не меняли ничего. По ходу проект заброшен. Так что я использую Robotium и не советую с него слазить.

[@Virtyoz]

Забавно читать такие комменты из будущего, 2019 :)