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

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

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

lemur.find('./EditText/').text('user@example.com')
lemur.find('.android.widget.Button', 'Login').click()
assert(lemur.find(./Progress/), 'Progress is not shown')

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

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

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

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

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

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

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

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

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

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