В каком файле можно убедиться что espresso framework был импортирован в android studio

Обновлено: 03.07.2024

Вопрос 0, с которым следует разобраться, — это принять решение, какой же фреймворк для автоматизации выбрать 🙂

При поиске фреймворка для автоматизации мобильного приложения стоит выбор: нативные инструменты (Espresso для Android / XCUITest для iOS) или кроссплатформенные решения (Appium). Я тестирую мобильное приложение, и нашей команде тоже пришлось искать ответ на вопрос: «А что же лучше?». Взвесив все «за» и «против», мы приняли решение использовать нативные инструменты.

Sportmaster Lab , Санкт-Петербург, Москва, Красноярск , От 100 000 до 250 000 ₽

В этой статье я собрала несколько вопросов, с которыми столкнулась при написании первых автотестов на Espresso — нативном фреймворке от Google для автоматизации приложений под Android, и предложила решения, которые внедряла по ходу своей работы.

Вопрос 1. Что же нужно писать в @Rule и почему примеры из интернета не всегда работают?

Если вы погуглите, то в любом источнике найдёте вот такой пример правила для исполнения тестов в Espresso (Java):

Причина того, почему это правило не срабатывает, может состоять в том, что тестируемое приложение стартует не с MainActivity. Например, если launcher, то есть активити, с которой запускается приложение, — SplashActivity (понять это можно по splash-скрину, который показывается при запуске приложения), то именно её нужно указывать в правиле. Чтобы узнать наверняка, с какой активити стартует приложение, нужно найти файл app/src/main/AndroidManifest.xml , найти список всех активити и посмотреть, какая из них имеет категорию android.intent.category.LAUNCHER .

То есть в нашем примере корректное правило выглядит так:

Вопрос 2. Где брать id элементов для автотестов на Espresso?

Layout Inspector позволяет просматривать иерархию элементов и все характеристики каждого элемента на выбранном экране. Экраны в Layout inspector меняются в режиме реального времени: как только вы на эмуляторе перешли на другой экран, Layout inspector обновится и покажет данные для открывшегося экрана. Однако минус последней версии Layout inspector-а состоит в том, что он не позволяет копировать данные из панели характеристик (например, скопировать текст, который содержится в нужном для теста элементе).

Если для вас это критично, то можно использовать предыдущую версию Layout Inspector-а — Legacy Layout Inspector. Он позволяет копировать характеристики элементов, но не обновляет экраны в режиме реального времени, необходимо открывать отдельное окно Inspector-а для каждого экрана. Какую версию Inspector-а лучше использовать, решать, конечно же, вам, но в любом случае этот инструмент — маст хэв при написании автотестов на Espresso.

Вопрос 3. Два элемента на экране имеют одинаковый id, что делать?

В примерах тестов на Espresso можно найти очень простые варианты кода:
onView(withId(R.id.id_example)).perform(click()) . Но что, если, допустим, два поля ввода на одном экране имеют одинаковые id?

В ряде случаев одним matcher-ом (matcher — условие, по которому ищется элемент на экране; в веб-автоматизации — локатор) сложно максимально точно конкретизировать, какой именно элемент нужен в конкретном шаге. С другой стороны, добавлять matcher-ы в огромном количестве тоже не стоит. В случае с полями ввода было достаточно добавить всего один дополнительный matcher для корректного определения каждого элемента:

Matcher-ов может быть и 3, и 4, если их добавление в тест действительно оправдано. Главное — задавать себе вопрос: сколько matcher-ов необходимо и достаточно, чтобы со стопроцентной точностью найти именно этот элемент?

Вопрос 4. Какие есть методы ожидания?

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

Но увы, ожидание — это одна из самых первых проблем, с которыми вам придётся столкнуться уже на начальном этапе, если тестируемое приложение стартует со Splash-скрина — без методов ожидания тесты начнут исполняться на SplashActivity и, конечно, упадут.

В любом источнике, где говорится о методах ожидания в любых автотестах, не только для мобильных приложений, чётко и ясно написано: НЕ ИСПОЛЬЗОВАТЬ В ТЕСТАХ Thread.sleep() . Они делают тесты менее стабильными, плюс добавление Thread.sleep-ов искусственно удлиняет время прохождения теста.

В Espresso в качестве способов ожидания предлагается использование Idling resources. Однако есть один нюанс: в вашем приложении уже должны быть добавлены Idling Resources, чтобы вы могли использовать их в своих тестах. Но на момент, когда вы начинаете писать автотесты, в вашем приложении этого может и не быть (например, в случае, если изначально написание автотестов командой не планировалось).

Когда мы столкнулись с этой проблемой, то решили поступить таким образом: пока команда Android добавляла Idling Resources для автотестов (да, здесь необходима помощь и поддержка команды разработки), я писала автотесты с Thread.sleep() , чтобы не терять время и добавлять основную логику проверок, хоть и без правильных и рекомендованных методов ожидания. Я не хочу сказать, что Thread.sleep() — это суперспособ, однако он может стать вашим спасением на тот случай, если на добавление правильного решения требуются время и ресурсы команды разработки, а приостанавливать написание автотестов из-за этого не хочется.

Вопрос 5. Почему scrollTo не работает?

Как вариант, потому что в вашем приложении используется не просто ScrollView и не HorizontalScrollView , а NestedScrollView . Ни scrollTo , ни остальные методы для поиска элемента в RecyclerView в Espresso не работают с NestedScrollView , если элемент, который нужен вам для теста, не является видимым в момент обращения к RecyclerView .

Пока что я в поиске решения этой проблемы. Для нескольких кейсов в моём приложении мне, как альтернатива, подходит swipeUp() , но он точно не поможет, если у вас RecyclerView с 50 элементами и обратиться нужно к 49-му.

Вопрос 6. Я только начинаю писать автотесты на Espresso и понятия не имею, как описывать PageObjectModel.

Ответ: пробуйте писать так, как можете и как понимаете. Например, просто пишите набор команд, необходимых для выполнения теста. Напишите так 5-10 тестов на одну функциональность. За это время у вас появится понимание, какие части кода можно переиспользовать, чтобы избежать дублирования, и как должны выглядеть ваши PageObjectModel .

Мои первые тесты выглядели примерно вот так (Kotlin):

И только потом они превратились в (Kotlin):

Решения и подходы, предложенные мной, разумеется, не единственные. Однако я надеюсь, что они помогут начинающим автоматизаторам сэкономить часы ресёрча и поверить, что писать автотесты и правда просто! Главное — начать 🙂

Здравствуйте, друзья. В преддверии старта курса «Mobile QA Engineer», хотим поделиться с вами переводом интересного материала.

Что такое Espresso?

Нет, это не напиток, который вы пьете каждый день, чтобы взбодриться. Espresso — это тестовый фреймворк с открытым исходным кодом, разработанный Google. Он позволяет выполнять сложные тесты пользовательского интерфейса на реальном устройстве или эмуляторе. Потребуется ли время, чтобы начать писать сложные тесты для Android?

Возможно. Но ничего не мешает вам сделать первый шаг и научиться писать простые тест-кейсы для Android с помощью фреймворка Espresso прямо сейчас.

Расскажите поподробнее об автоматизации?

Конечно. Автоматизация — это способ ускорить выполнение тестов, сделать их более эффективным и масштабируемым. Ручное тестирование очень важно, но наличие автоматических тестов — гораздо лучший вариант в перспективе.

Существует в основном два типа тестовых фреймворков:

Фреймворки, которым не нужен доступ к исходному коду и которые не интегрированы как часть проекта. Например, WebDriver, Appium, QTP.
Фреймворки, которым нужен доступ к исходному коду. Например, Espresso, KIF (Keep It Functional).

Основные компоненты Espresso

Есть три типа методов, доступных в Espresso:

ViewMatchers — позволяют найти объект в текущей иерархии представлений
ViewAssertions — позволяют проверить состояние объекта и подтвердить, что состояние соответствует критериям
ViewActions — эти методы позволяют выполнять различные действия с объектами.

Создание простого приложения для автоматизации

Первое, что нам нужно сделать, — это создать приложение, которое мы будем автоматизировать. Давайте создадим проект в Android Studio. Для этого, конечно, необходимо, чтобы Android Studio был установлен у вас на компьютере.

1. Откройте Android Studio и создайте Bottom Navigation Activity.

Android Studio. Окно «Create New Project»

2. Назовите проект и выберите язык программирования.

Android Studio. Указание имени проекта

3. Перейдите в папку androidTest

Android Studio. Инструментальный тест.

Как вы можете видеть, там написан только один тест, и это не UI-тест, а JUnit-тест.

Сейчас нам нужно добавить простой тест пользовательского интерфейса. Для этого сначала создадим правило для открытия MainActivity.

Давайте добавим импорт аннотации JUnit Rule:

Следующее, что нужно сделать, — это добавить строку кода, указанную ниже, в дополнение к аннотации RunWith:

Теперь мы видим, что ActivityTestRule выделен красным. Это означает, что нам необходимо импортировать функцию ActivityTestRule. Но прежде нам нужно добавить библиотеку, способную сделать это. В двух словах, для этой задачи нам нужна помощь Gradle — системы автоматизации сборки, созданной специально для этой цели.

Давайте перейдем к файлу конфигурации Gradle и добавим эту библиотеку. Откройте файл с именем build.gradle (Module: app) и добавьте строку, указанную ниже:

Android Studio. Добавление зависимости.

После добавления, нужно нажать кнопку для синхронизации проекта и затем вернуться к файлу с реализацией теста.

Теперь, когда библиотека добавлена, следующим шагом будет ее импортирование в файле с инструментальным тестом:

Android Studio. Импорт ActivityTestRule.

Хорошо, теперь мы готовы добавить наш первый тест. Введите этот код в ExampleInstrumentedTest:

Android Studio. Добавление теста и импортирование дополнительных элементов

Запуск Espresso-тестов

Щелкните правой кнопкой мыши на нашем тесте слева и выберите «Run ExampleInstrumentedTest».

Поскольку это UI-тест, а не модульный тест, дальше мы увидим окно с выбором устройства, на котором мы хотели бы запустить его. У меня уже есть «Nexus 5X» в качестве устройства, поэтому мне нужно просто выбрать его.

В вашем случае, если вы никогда не развертывали Android-проект, выберите ваше реальное Android-устройство или нажмите «Create New Virtual Device» и создайте новое эмулируемое устройство для запуска тестов. Это может быть любое устройство из списка, на котором бы вы хотели запустить тесты.

Нажмите «ОК» и приготовьтесь увидеть магию!

Android Studio. Результаты выполнения теста

Как вы можете видеть, у нас есть набор из двух пройденных тестов: модульного теста, который уже был там, после создания проекта, и нашего теста «clickHomeButton», который мы только что написали.

Android Studio. Выполненный тест.

Как видно из названия, мы нажали только одну кнопку в нижней панели навигации, которая называется «navigation_home» в иерархии MainActivity.

Давайте проанализируем что мы делали в этой цепочке методов:

1. Вызываем «onView». Этот метод является методом типа ViewMatchers. Мы находим объект в нашем Activity для выполнения чего-либо.
2. Далее мы вызываем perform(click()). Этот метод является методом типа ViewActions. Мы указываем конкретное действие, которое нужно выполнить в этом случае — сделать одно нажатие (click). В Espresso доступно еще много методов действий, например:
3. Последнее, что нам нужно сделать, это подтвердить, что действие, которое мы сделали, действительно соответствует нашим критериям, и для этого мы выполняем метод check(isDisplayed()), который является методом типа ViewAssertions. В этом случае мы проверяем, что этот объект (представление) действительно отображался на экране после выполнения действия нажатия.

Иерархия представлений в Android

Уважаемый читатель, я надеюсь, что смог объяснить вам, как писать базовые UI-тесты для Android с помощью Espresso.

Однако, вероятно, не так просто понять, что именно здесь произошло, если не знать, где все эти кнопки расположены и откуда они берутся. Для того, чтобы это узнать, нам нужно перейти в папку «res» с левой стороны, открыть папку «menu» и выбрать «bottom_nav_menu.xml».
Вот что мы увидим там:

Android Studio. Иерархия представления нижнего меню навигации.
Как видите, это строка, которая присваивает имя элементу меню:

Именно это мы используем в нашем коде для запуска тестов. Также есть кнопки меню “navigation_dashboard” и “navigation_notifications”, доступные внизу, так что давайте продолжим и используем их в наших тестах.

Еще больше Espresso-тестов

Нам нужно вернуться к файлу ExampleInstrumentedTest и добавить туда еще пару тестовых функций:

Единственное, что мы добавили, — это проверка еще нескольких элементов меню: “navigation_dashboard” и “navigation_notifications”.

Android Studio. Добавляем еще два теста.

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

Android Studio. Результаты выполнения тестов.

Все 4 теста пройдены. Все представления были найдены, нажаты и подтверждены в иерархии представлений.

Заключение

Espresso — это мощное решение для запуска UI-тестов. Теперь, когда вы знаете, как они создаются, вы готовы писать намного более мощные и сложные тесты.

Вторая глава книги «Раскрытие Android Framework» г-на Джина Тайяна посвящена настройке и созданию среды разработки Android и объясняет, как отлаживать Android Framework в затмении, но теперь все в основном используют среду разработки Android Studio, как и в Android. Как отлаживать Android Framework в студии? На самом деле, многие посты в блогах на эту тему были тщательно описаны, но у меня есть некоторый опыт обращения к этим постам в блоге. Я также буду записывать их здесь через этот пост.

1. Загрузите и скомпилируйте исходный код Andriod

2. Создайте файл проекта Android Studio

Поскольку вы хотите использовать Android Studio (в дальнейшем именуемую AS) для отладки исходного кода Android Framework (в дальнейшем именуемый AF), вы должны сначала использовать AF для открытия AF. Мы знаем, что исходный код AF находится в файле frameworks исходного каталога Android, но использование AS для непосредственного открытия этого исходного кода Нет, мы должны сначала создать файл проекта, который AS может открыть.

Для этого сначала перейдите в каталог исходного кода Android и выполните следующую команду, чтобы сгенерировать idegen.jar.

Появится следующая подсказка, чтобы указать, что выполнение было успешным

Затем выполните следующую команду, чтобы сгенерировать файл проекта android.ipr и файл конфигурации проекта android.iml, который может быть открыт AS

Следующие подсказки указывают на успех

И два файла android.ipr и android.iml создаются в корневом каталоге исходного кода Android. В некоторых статьях упоминается файл android.iws, но этот файл фактически не включен в этот пост. Что использовать

На этом этапе создается файл проекта android.ipr и конфигурационный файл android.iml, которые AS может открыть. Фактически, детская обувь здесь также может относиться к разработке по пути исходного кода. Файл / tools / idegen / README.

3. КАК импортировать исходный код Android

Теперь, когда файл android.ipr создан, мы используем AS, чтобы открыть файл android.ipr напрямую. Не волнуйтесь, нам нужно только отладить AF, но сгенерированный здесь android.ipr содержит в основном все модули в исходном коде Android, так что если мы просто откроем android.ipr, как это, то ожидание нас будет долгим процессом сканирования индекса.

Итак, как заставить AS загружать только модуль AF? Здесь нам нужно использовать файл android.iml для его настройки. Откройте файл android.iml и найдите excludeFolder, мы можем найти место для настройки.

Теперь, когда шаблон предоставлен здесь, нам просто нужно следовать инструкциям, таким как не загружать модуль разработки и только добавлять следующую конфигурацию

Поскольку нам нужно только загрузить модуль frameworks, мы можем удалить все остальные модули здесь, а затем открыть файл android.ipr через AS, чтобы узнать, что, черт возьми, другие модули.

В процессе настройки я долго боролся с этим. Позже я обнаружил, что в меню меню «Показать параметры» на рисунке выше есть меню «Показать исключенные файлы». Удалите его, чтобы отображались только платформы.

Здесь мы успешно импортировали модуль AF через AS.

4. Отладка Android Framework

После импорта AF необходимо рассмотреть возможность отладки AF. Здесь модуль com.example.test был реализован заранее. Он имеет только Activity, которая содержит ListView. Мы устанавливаем точку останова в AbsListView AF.

Затем откройте эмулятор. Обратите внимание, что, поскольку я извлекаю исходный код Android 8.1, эмулятор здесь также является эмулятором для открытого API 27. В противном случае точка останова может быть не найдена. Если вы будете отлаживать на реальной машине, это будет еще хуже.

Выполните-> Присоединить отладчик к процессу Android в AF, выберите соответствующий модуль com.example.test, затем откройте модуль com.example.test в симуляторе и уменьшите ListView, чтобы зафиксировать точку останова в Android Studio. Удачная отладка, потому что компьютерная карта сравнения здесь не показана, я успею заполнить ее позже.

На этом, внедрение импорта и отладки Framework в Android Studio подошло к концу.

Начиная с версии 2.0, эспрессо является частью Android Support Repository, что делает добавление Espresso в проект более легким.

Но, прежде чем перескакивать к API Эспрессо , давайте рассмотрим чем этот фреймворк отличается от других:

1) API тестов Espresso выглядит как обычный английский текст, что позволяет быстро научиться работать с ним.
2) Имеет маленький API
3) Espresso быстро запускается
4) Поддержка Gradle+Android Studio

Добавляем Espresso в проект

1. Прежде всего мы должны установить Android Support Repository

2) Добавьте зависимости в файл build.gradle:

3) Наконец, добавьте команду запуска тестов в defaultConfig:

Главные компоненты в Espresso

Espresso состоит из трех основных компонентов:

ViewMatchers – позволяетнайти View на экране
ViewActions – позволяет взаимодействовать с View
ViewAssertions — проверяет состояние View

Для простоты, вы можете использовать эти шпаргалки:
• ViewMatchers — «что-то» найти
• ViewActions — «сделать что-то»
• ViewAssertions — «что-то» проверить

Например, когда вам нужно будет что-то проверить (как, некоторый текст отображается на экране), вы будете знать, что для этого вам понадобится ViewAssertion.

Ниже приведен пример теста Espresso и показано расположение главных компонентов:

Простой тест с использованием onView()

Напишем тест для этого приложения:

Обратите внимание, что мы не указываем явно какие с какими View мы взаимодействуем (EditText или Button), мы просто говорим, что мы ищем View с конкретным идентификатором.
Кроме того, при нажатии на кнопку «Далее» а также при проверке текста, мы не должны писать специальный код, чтобы рассказать эспрессо, что мы перемещаться на другую активити.

Теперь, если мы действительно хотим запустить этот тест, то он должен быть помещен в класс. В Gradle, тесты хранятся в папке: ваше_приложение/src/androidTest/java.

Это пример класса теста, и его основные характеристики:

Простой тест с использованием onData()

Всякий раз, когда у вас есть ListView, GridView, Spinner или другие View, основанные адаптере, вы должны будете использовать метод onData () для того, чтобы взаимодействовать с элементом из этого списка. Метод onData () ориентирован на непосредственно данные, предоставленные вашим адаптером. Что это значит, мы сейчас увидим:

Представим, что у нас есть приложение, в котором мы должны выбрать страну из Spiner’а. При выборе пункта название выбранного пункта отображается рядом со Spiner’ом:

А вот тест для тестирования этого приложения:

Как мы видим, Spinner основан на массиве строк. Если вместро строк используется собственный класс, то мы должны указать на это. Рассмотрим тест на примере списка книг:

Вот так теперь выглядит тест:

Откуда взялся метод withBookTitle вы можете посмотреть в исходниках на GitHub, ссылка на который расположена в конце статьи.

DataInteractions

Espresso имеет несколько полезных методов для взаимодействия с данными.

atPosition() – может быть полезен, когда элементы расположены в определенном порядке и вы точно знаете на какой позиции находится данный элемент.

inRoot() — используется при не стандартных окнах. Один из сценариев использования это функция автозаполнения (подсказки) у EditText. Пример:

onChildView() – этот DataInteraction уточнить запрос, позволяя взаимодкействовать с конкретным View из списка. Например, у нас есть список элементов и у каждого элемента есть кнопка удаления. Вы хотите нажать кнопку «Удалить» у конкретного пункта в списке:

inAdapterView() — нужен для взаимодействия с конкретным классом адаптера. По умолчанию Espresso работает со всеми видами адаптеров. Это может быть полезно при работе с ViewPager’ом или Fragment’ами, когда вам нужно взаимодействовать с тем адаптером, который отображается на экране или же, если на вашем экране больше одного адаптера. Пример:

Espresso и RecycleView

RecyclerView — это UI-компонент, предназначенный для визуализации набора данных в виде ListView или GridView и призван заменить их обоих. RecycleView не является наследником AdapterView, поэтому мы больше не сможем использовать метод onData() для взаимодействия с элементами списка.

Читайте также: