Полное раскрытие: я один из авторов Espresso.
И Espresso, и Robotium - это инструментальные фреймворки, то есть они используют Android Instrumentation для проверки и взаимодействия с тестируемыми Activity .
В Google мы начали с использования Robotium, потому что он был удобнее стандартного инструментария (снимаем шляпу перед разработчиками Robotium за то, что это так). Однако это не удовлетворило нашу потребность в среде, которая облегчила бы написание надежных тестов для разработчиков.
Основные преимущества Espresso по сравнению с Robotium:
Синхронизация. По умолчанию логика инструментального тестирования выполняется в другом (инструментальном) потоке, нежели операции пользовательского интерфейса (обрабатываются в потоке пользовательского интерфейса). Без синхронизации тестовых операций с обновлениями пользовательского интерфейса тесты будут подвержены нестабильности, т.е. будут случайным образом завершаться ошибкой из-за проблем со временем. Большинство авторов тестов игнорируют этот факт, некоторые добавляют механизмы ожидания / повтора и еще меньше реализуют более сложный код безопасности потоков. Ни один из них не идеален. Espresso заботится о безопасности потоков, бесшовно синхронизируя тестовые действия и утверждения с пользовательским интерфейсом тестируемого приложения. Robotium пытается решить эту проблему с помощью механизмов сна / повторных попыток, которые не только ненадежны, но и заставляют тесты работать медленнее, чем необходимо.
API. Espresso имеет небольшой, четко определенный и предсказуемый API, который открыт для настройки. Вы сообщаете фреймворку, как найти элемент пользовательского интерфейса, используя стандартные средства сопоставления hamcrest, а затем инструктируете его либо выполнить действие, либо проверить утверждение на целевом элементе. Вы можете сравнить это с API Robotium, где автор теста должен выбирать из более чем 30 методов щелчка. Кроме того, Robotium предоставляет опасные методы, такие как getCurrentActivity (что в любом случае означает текущий?) И getView, которые позволяют вам работать с объектами вне основного потока (см. Пункт выше).
Четкая информация об отказе. Espresso стремится предоставить обширную отладочную информацию в случае сбоя. Кроме того, вы можете настроить способ обработки сбоев в Espresso с помощью собственного обработчика сбоев. Я давно не пробовал, но предыдущие версии Robotium страдали от непоследовательной обработки сбоев (например, метод clickOnView проглатывал SecurityExceptions).
В отличие от предыдущего ответа, Espresso поддерживается во всех версиях API со значительным количеством пользователей (см. Http://developer.android.com/about/dashboards/index.html ). Он работает с некоторыми из старых версий, но их тестирование было бы пустой тратой ресурсов. Кстати о тестировании ... Espresso проверяется при каждом изменении с помощью комплексного набора тестов (с охватом более 95%), а также большинства приложений для Android, разработанных Google.