Разнообразные среды автоматизации тестирования для приложений React Native

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

Дальнейшее чтение о Smashing:

• Создание вашего первого приложения для iOS с помощью JavaScript
• Почему вы должны рассмотреть React Native для своего мобильного приложения
• Автоматизация тестирования приложений, игр и мобильного Интернета
• Рендеринг на стороне сервера с помощью React, Node и Express
• Примечания о клиентской доступности

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

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

В этой статье мы рассмотрим, что доступно для тестирования приложений React Native. Сначала я объясню некоторые ключевые особенности React Native, а затем расскажу, как реализовать эти тесты. Во-вторых, я разделю методы и фреймворки тестирования на три уровня (модульный, интеграционный, функциональный) и приведу примеры для каждого из них. Наконец, я приведу простые примеры того, как реализовать тесты, используя самые популярные платформы автоматизации тестирования с открытым исходным кодом для функционального тестирования приложений.

Базовая архитектура приложений React Native

Все началось с React более трех лет назад, когда Facebook представил веб-разработчикам свой фреймворк. Он должен был стать популярным не только потому, что был создан и разработан Facebook, но и из-за возможностей, которые он предоставил веб-разработчикам, и особенно из-за того, как он изменил то, как мы создаем приложения.

Однако концепция этого типа структуры «научись один раз, пиши где угодно» не была новой; мы уже видели, что библиотеки JavaScript делают подобные вещи (среди прочего, Sencha, PhoneGap и Appcelerator), но в React было что-то лучше, что повлияло на привычки разработчиков и то, как они разбивают пользовательский интерфейс приложения на отдельные компоненты.

React Native не использует DOM для рендеринга. Вместо этого он отображает собственные представления пользовательского интерфейса, что означает, что вы используете собственные компоненты, предоставляемые операционной системой. Такой процесс создания продукта, когда вы заменяете DOM API более декларативным API, дает разработчикам более связный и упрощенный уровень абстракции.

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

Основное отличие, а также преимущество нативных мобильных устройств по сравнению с веб-версиями заключается в том, что вместо того, чтобы запускать реализацию на основе JavaScript в браузере и отображать элементы HTML, мы теперь полагаемся на встроенный JavaScriptCore в приложениях, которые зависят от платформы. Элементы пользовательского интерфейса.

Автоматизация тестирования на разных уровнях: модульный, интеграционный, компонентный и функциональный

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

В этой статье я расскажу о методах тестирования и платформах автоматизации на трех уровнях. Основное внимание уделяется функциональному тестированию самого высокого уровня, но приложения React Native можно тестировать — и тестирование можно автоматизировать — как минимум на следующих уровнях:

• Модульное тестирование
  Это может быть даже такое базовое, как тестирование объектов и методов JavaScript на уровне компонентов.
• Тестирование компонентов
  Каждый компонент можно протестировать визуально или функционально. ReactTestUtils предоставляет простую платформу для тестирования компонентов React.
• Интеграционное тестирование
  Следующим идет интеграционное тестирование, которое представляет собой этап, когда группа различных модулей обычно тестируется как единое целое.
• Функциональное тестирование
  Функциональное тестирование — это тип тестирования черного ящика, который фокусируется на пользовательских требованиях и взаимодействиях и охватывает все базовое программное обеспечение, все взаимодействия с пользователем и приложение как единое целое.

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

В то время как модульное тестирование может выполняться на уровне компонентов, автоматизация функционального тестирования предоставляет лучшие возможности для тестирования более крупных объектов в приложении React Native. С React Native модульное тестирование логики компонентов можно выполнять изолированно, используя традиционные библиотеки JavaScript и заставляя React Native возвращать обычные компоненты вместо нативных. С функциональными средами автоматизации тестирования компоненты пользовательского интерфейса являются частью приложения, и их легко тестировать как единое целое.

Я разделю эти фреймворки на кроссплатформенные фреймворки и фреймворки для конкретных платформ, как показано на рисунке ниже.

Лучшая часть приложений React Native заключается в том, что они полностью нативные для обеих основных мобильных платформ (Android и iOS). Это означает, что мы получаем больше фреймворков, инструментов и нативных методов для целей тестирования. Мы рассмотрим функциональные фреймворки автоматизации тестирования в разделе ниже под названием «Использование функциональных фреймворков автоматизации тестирования с приложениями React Native».

Давайте начнем с возможностей модульного тестирования, используя для иллюстрации тест JavaScript.

Модульное тестирование с помощью Jest и Jasmine

По умолчанию React Native предоставляет тесты Jest для модульного тестирования, и это работает как для Android, так и для iOS. В настоящее время покрытие тестами не идеально, но, согласно Facebook, в React Native будут представлены дополнительные возможности модульного тестирования, и пользователи уже могут создавать свои собственные.

Jest использует основанную на поведении платформу Jasmine в качестве основы для тестирования кода JavaScript. Каждый тестовый пример начинается с вызова функции describe() , аналогично тому, как JUnit использует класс TestCase . Функция description describe() принимает два параметра: описание и название теста, а также функцию, которую необходимо выполнить. Функция it() включает в себя все этапы тестирования и (аналогично JUnit) предоставляет набор функций expect() .

Вот пример тестового сценария Jasmine для приложения-плеера.

 describe("Player", function() { var player; var song; beforeEach(function() { player = new Player(); song = new Song(); }); it("should be able to play a song", function() { player.play(song); expect(player.currentlyPlayingSong).toEqual(song); //demonstrates use of custom matcher expect(player).toBePlaying(song); }); describe("when song has been paused", function() { beforeEach(function() { player.play(song); player.pause(); }); it("should indicate the song is paused", function() { expect(player.isPlaying).toBeFalsy(); // demonstrates use of 'not' with a custom matcher expect(player).not.toBePlaying(song); }); it("should be possible to resume", function() { player.resume(); expect(player.isPlaying).toBeTruthy(); expect(player.currentlyPlayingSong).toEqual(song); }); }); // demonstrates use of spies to intercept and test method calls it("tells the current song whether the user has made it a favorite", function() { spyOn(song, 'persistFavoriteStatus'); player.play(song); player.makeFavorite(); expect(song.persistFavoriteStatus).toHaveBeenCalledWith(true); }); //demonstrates use of expected exceptions describe("#resume", function() { it("should throw an exception if song is already playing", function() { player.play(song); expect(function() { player.resume(); }).toThrow("song is already playing"); }); }); });

Этот базовый пример показывает, как Jasmine можно использовать для тестирования функциональности приложения, но при этом основное внимание уделяется тестированию на уровне методов. Кроме того, React Native предоставляет некоторые базовые возможности для тестирования интегрированных компонентов. Это работает как для нативных, так и для JavaScript-компонентов и обеспечивает связь между ними через мост.

Интеграционное тестирование

На данный момент интеграционные тесты, отмеченные в сообществе React Native, доступны только для iOS и очень ограничены в своих возможностях по тестированию компонентов. Коммуникация проходит через мост и требует как собственных компонентов, так и компонентов JavaScript. Для этой функциональности доступны два компонента для реализации настраиваемых интеграционных тестов: RCTestRunner и RCTestModule.

Базовый пример Objective-C для создания тестового каркаса приложения для iOS будет начинаться так:

 @implementation ExampleTests { RCTTestRunner *_runner; } - (void)setUp { [super setUp]; _runner = RCTInitRunnerForApp(@"IntegrationTestHarnessTest", nil); } - void()testExampleTests { [_runner runTest:_cmd module:@"ExampleTests"] } @end

Однако есть и другие способы запустить интеграционное тестирование и распространить его на Android и iOS. Хорошей альтернативой для запуска как модульных, так и интеграционных тестов является Mocha, который предоставляет многофункциональную тестовую среду JavaScript, работающую на Node.js. Mocha также предоставляет разработку на основе поведения (BDD), разработку на основе тестирования (TDD) и интерфейсы QUnit для тестирования.

Для функционального тестирования пользовательского интерфейса я расскажу о самых известных и наиболее часто используемых средах автоматизации тестирования, включая Appium, Calabash, XCTest и некоторые другие.

Использование функциональных фреймворков автоматизации тестирования с приложениями React Native

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

Лучший выбор — если ваше приложение будет работать на нескольких платформах ОС — это фреймворк, который поддерживает несколько платформ и обеспечивает надежную основу для автоматизации тестирования. В мобильных устройствах термин «кроссплатформенный» относится к фреймворку, который предоставляет одинаковый API, инструменты и возможности как для Android, так и для iOS.

Кроме того, доступен ряд отличных платформ для конкретных платформ. Естественно, каждый фреймворк создавался для определенной платформы, и в большинстве случаев его легче адаптировать для этой платформы. Помимо Appium и Calabash, в этой статье я расскажу о четырех платформах для конкретных платформ: Robotium и Espresso для Android и XCTest и EarlGrey для iOS.

Когда дело доходит до автоматизации тестирования, имейте в виду, что приложения, созданные с помощью React Native, полностью нативные как для iOS, так и для Android; следовательно, с ними прекрасно будут работать функциональные среды автоматизации тестирования.

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

 <Radio onSelect={this.onSelect.bind(this)} defaultSelect={this.state.optionSelected - 1}> <Option color="black" selectedColor="#000000"> <Item title="First option" description="First radio button"/> </Option> <Option color="black" selectedColor="#000000"> <Item title="Second option" description="Second radio button"/> </Option> <Option color="black" selectedColor="#000000"> <Item title="Third option" description="Third radio button"/> </Option> </Radio>

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

Кроссплатформенные фреймворки

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

Аппиум

Appium — это фреймворк для автоматизации тестирования с открытым исходным кодом и инструментом проверки, который хорошо подходит для нативных, гибридных и мобильных веб-приложений. Он использует JSONWireProtocol внутри для взаимодействия с приложениями iOS и Android, используя Selenium WebDriver. Из-за этого Appium очень хорошо работает и для мобильного Интернета, и варианты использования очень похожи, если Selenium используется для веб-тестирования.

Фактически, в прошлом году Appium стал восходящей звездой в области автоматизации тестирования мобильных устройств. Первоначально он был создан для обеспечения кроссплатформенной поддержки для обеих основных платформ, Android и iOS.

Кроссплатформенность означает, что фреймворк и его скрипты работают одинаково на обеих платформах. Кроме того, Appium обеспечивает фантастическую поддержку языков программирования — разработчики могут писать тесты, используя свой любимый язык (например, Java, Ruby, Python, C#), инструменты и среду. Также легко начать работу, создавать и поддерживать многоразовые тесты, а также выполнять эти тесты на реальных физических устройствах.

Когда дело доходит до приложений на базе React Native, JavaScript не обязательно требуется; тесты могут быть написаны на любом языке. Например, скрипты Appium могут выглядеть так:

 driver.findElement(By.id("com.example.app:id/radio0")).click(); driver.findElement(By.id("com.example.app:id/radio1")).click(); driver.findElement(By.id("com.example.app:id/radio2")).click(); driver.findElement(By.id("com.example.app:id/editText1")).click(); driver.findElement(By.id("com.example.app:id/editText1")).sendKeys("Simple Test"); driver.findElement(By.name("Answer")).click(); // or alternatively like this: driver.findElement(By.id("com.example.app:id/button1")).click();

Итак, как эти функции WebDriver получают доступ к приложениям, работающим на устройствах? По сути, Appium запускает тестовый скрипт на устройстве или эмуляторе, который затем создает сервер и прослушивает команды с основного сервера Appium. Это то же самое, что и сервер Selenium, который получает HTTP-запросы от клиентских библиотек Selenium. Разница между Android и iOS показана на картинке ниже:

В iOS Selenium WebDriver получает команду из скрипта Appium (например, click() ) и отправляет ее в виде JSON через HTTP-запрос на сервер Appium. Appium знает контекст автоматизации и отправляет эту команду на командный сервер Instruments, который ждет, пока клиент команд Instruments подберет ее и выполнит с помощью bootstrap.js в среде iOS Instruments. После выполнения команды командный клиент Instruments отправляет сообщение обратно на сервер Appium, который регистрирует все, что связано с командой, в своей консоли. Этот цикл продолжается до тех пор, пока тестовый сценарий не завершится.

На Android все работает почти так же, за исключением того, что используются фреймворки Selendroid и UiAutomator. Короче говоря, Appium переводит команды WebDriver в команды UiAutomator (уровень API 17 или выше) или Selendroid (уровень API 16 или ниже). На физическом устройстве bootstrap.jar запускает TCP-сервер, который получает команды от TCP-клиента. Процесс похож на iOS.

Если вы заинтересованы в том, чтобы начать работу с Appium, доступно множество материалов, включая пошаговые инструкции и учебные пособия по Appium.

Кальян

Еще одна отличная кроссплатформенная среда тестирования — Calabash, которая позволяет любому писать тесты для мобильных приложений. Основное отличие состоит в том, что тесты Calabash написаны на Cucumber. Идея использования такого языка для тестов потрясающая: сам тест похож на спецификацию, и все тесты просты и легко читаемы, но при этом могут выполняться системой автоматизации.

По сравнению с Appium Calabash предоставляет более простой способ создания кроссплатформенных тестов для Android и iOS. Это связано с простым словарным запасом и языком, ориентированным на спецификации, что делает тесты Calabash идентичными на обеих платформах. Настоящие тесты написаны на Gherkin и выполняются на Cucumber.

Из-за этих возможностей различия между Calabash, работающим в приложениях для Android и iOS, незначительны. Опять же, это не имеет значения для приложений React Native, поскольку все компоненты и пользовательские интерфейсы полностью соответствуют этим платформам.

Однако основной процесс тестирования и создания тестов остается прежним. Тесты Calabash (и Gherkin) включают функции, сценарии и этапы. Рекомендуемый подход заключается в том, чтобы сначала заполнить описания самого высокого уровня: функции, затем сценарии, а затем фактические шаги. Хорошее эмпирическое правило — сначала создать функции Calabash.

В приведенном ниже примере показано, как наше приложение и его компоненты пользовательского интерфейса (переключатели, текстовое поле и кнопка) будут реализованы в Calabash:

 Feature: Answer the question feature Scenario: As a valid user, I want to answer app question, I wait for text "What is the best way to test application on a hundred devices?" Then I press radio button 0 Then I press radio button 1 Then I press radio button 2 Then I enter text "Simple Test" into field with id "editText1" Then I press view with id "Button1"

Шаги обычно начинаются с одного из given ключевых слов, then , when and или but . Однако это не обязательно; вместо этого они могут использовать * .

Calabash также широко используется не разработчиками, и его можно использовать для спецификаций продуктов и документации благодаря простому для понимания языку и логике. В конце концов, функции и сценарии завернуты в код Ruby.

Настроить Calabash и начать с ним работать несложно. Если у вас установлены Bundler и Ruby (или rbenv), просто нажмите эти несколько строк в консоли, и вскоре среда Calabash будет настроена:

 $ gem install calabash-android $ gem install calabash-cucumber

Это позаботится об установке Calabash-Android и Calabash-iOS, и ваше путешествие с автоматизацией тестирования может начаться.

Фреймворки для конкретных платформ

Когда дело доходит до автоматизации тестов приложений для Android и iOS, использование платформенных фреймворков имеет определенные преимущества перед кросс-платформенными. Например, некоторые фреймворки тесно связаны с SDK и IDE, которые легко доступны, пока приложение находится в стадии разработки. Давайте рассмотрим несколько примеров таких типов фреймворков для Android и iOS.

Роботиум и ExtSolo (Android)

Robotium был одним из первых фреймворков для тестирования, который работал с нативными и гибридными приложениями для Android. Тесты пользовательского интерфейса, созданные с помощью Robotium, позволяют выполнять функциональные, системные и пользовательские тесты для приложений Android, охватывая и обрабатывая несколько действий Android. На самом деле, Robotium обеспечивает поддержку очень ранних версий Android, начиная с уровня API 8.

Недавно Robotium был дополнен библиотекой ExtSolo, которая предоставляет различные полезные функции для тестирования приложений:

• автоматическое масштабирование кликов x и y для любого разрешения экрана;
• многоходовые перетаскивания;
• автоматический снимок экрана в момент сбоя теста;
• фиктивные местоположения (координаты GPS);
• изменение языка Android-устройства;
• контроль Wi-Fi соединения;

С кодом Java тесты легко создавать с помощью любого Java SDK и IDE. Основная функция, используемая в этом примере, — это findViewById , которая находит представление, идентифицируемое атрибутом id . Элемент пользовательского интерфейса также можно идентифицировать по имени, классу или другому атрибуту. Наш пример кода с атрибутом id будет выглядеть так:

 solo.clickOnView(solo.findViewById("com.example.app:id/radio0")); solo.clickOnView(solo.findViewById("com.example.app:id/radio1")); solo.clickOnView(solo.findViewById("com.example.app:id/radio2")); solo.enterText((EditText) solo.findViewById("com.example.app:id/editText1"), "Simple Test"); solo.clickOnView(solo.findViewById("com.example.app:id/button1"));

Здесь Robotium пытается найти элементы пользовательского интерфейса по id , описанию и другим характеристикам. К сожалению, это не всегда лучший подход и не обязательно хорошо работает с компонентами веб-просмотра. Однако с помощью библиотеки ExtSolo пользователи могут определять щелчки и другие взаимодействия с элементами пользовательского интерфейса, которые масштабируются в зависимости от разрешения. Кроме того, возможно жесткое кодирование координат, и они масштабируются при изменении разрешения экрана.

Если вы используете Robotium, начать работу с Robotium ExtSolo легко и просто. Просто клонируйте репозиторий для себя и соберите библиотеку:

 $ git clone https://github.com/bitbar/robotium-extensions $ ant clean instrument

После этого поместите недавно созданный файл .jar в папку libs в вашем проекте Android Studio и убедитесь, что ваш проект связан с ним. Все эти замечательные дополнительные функции и сервисы теперь в вашем рабочем пространстве.

Эспрессо (Android)

Инфраструктура тестирования Espresso предоставляет API-интерфейсы для написания тестов пользовательского интерфейса для имитации взаимодействия пользователя с приложением Android. Espresso API является легким и предоставляет три основных компонента: viewMatchers , viewActions и viewAssertions .

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

 // R class ID identifier for radio buttons onView(withId(R.id.radio0)).perform(click()); onView(withId(R.id.radio1)).perform(click()); onView(withId(R.id.radio2)).perform(click()); onView(withId(R.id.EditText1)).perform(click()); // Instead of R, we use getIdentifier onView(withId(getInstrumentation().getTargetContext().getResources() .getIdentifier("com.example.app:id/EditText1", null, null))).perform((typeText("Simple Test"))); onView(withId(getInstrumentation().getTargetContext().getResources() .getIdentifier("com.example.app:id/Button1", null, null))).perform(click());

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

На Google IO 2016 Google представила Espresso Test Recorder как неотъемлемую часть Android Studio. Хотя эта функция еще недоступна, ее определенно стоит подождать.

XCTest и KIF (iOS)

XCTest тесно связан с Xcode, но его можно использовать как с реальными устройствами iOS, так и с симуляторами. XCTest позволяет разработчикам писать тесты для компонентов любого уровня, а также предоставляет основу для возможностей тестирования пользовательского интерфейса. Тесты XCTest сгруппированы в подклассы XCTestCase. Написание любых тестов с помощью XCTest должно быть тривиальным для разработчиков iOS, поскольку XCTest полностью совместим как с Objective-C, так и со Swift.

KIF (сокращение от «держать его функциональным») — это среда тестирования интеграции iOS, которая тесно связана с тестовыми целями XCTest и использует их. Тесты KIF можно выполнять непосредственно в XCTestCase или любом подклассе. KIF позволяет легко автоматизировать приложения iOS, используя атрибуты специальных возможностей, которые ОС делает доступными для людей с нарушениями зрения.

Давайте посмотрим, как наши компоненты пользовательского интерфейса будут выглядеть с Objective-C:

 - (void)testClicksOnRadioButtons { [tester tapViewWithAccessibilityLabel:@”Radio1”]; [tester tapViewWithAccessibilityLabel:@”Radio2”]; [tester tapViewWithAccessibilityLabel:@”Radio3”]; [tester enterText:@”Simple Test” intoViewWithAccessibilityLabel:@”editText1”]; [tester tapViewWithAccessibilityLabel:@”Answer”]; }

В качестве альтернативы, со Swift тест будет выглядеть так же просто:

 testClicksOnRadioButtons() { let app = XCUIApplication() app.radiobutton[0].tap() app.radiobutton[1].tap() app.radiobutton[2].tap() app.staticTexts[“Simple Test”] app.button[0].tap() }

Обратите внимание, что этот высокоуровневый псевдокод требует дополнительного кода для полноценной работы. Если вам нужна дополнительная информация о XCTest и в целом об использовании возможностей тестирования Xcode, Apple поможет вам.

ЭрлГрей (iOS)

Чуть раньше в этом году Google открыл исходный код своей функциональной среды тестирования приложений для iOS под названием EarlGrey. Используемый внутри Google, он относительно хорошо работал с родными приложениями для iOS — YouTube, Google Calendar, Google Photos, Google Play Music и другими — и вызвал серьезный интерес. Чтобы начать работу с EarlGrey, вам потребуется установленная среда Xcode и базовые знания по разработке для iOS.

Между EarlGrey и Espresso много общего (да, оба разработаны Google), и их характеристики позволяют обоим фреймворкам работать и выполнять тесты быстро. Подобно Espresso, тесты EarlGrey автоматически ожидают событий (анимации, сетевых запросов и т. д.), прежде чем пытаться взаимодействовать с пользовательским интерфейсом. Это упрощает написание тестов, поскольку разработчикам не нужно беспокоиться о командах сна или ожидания. Кроме того, сам код легче поддерживать, поскольку он предоставляет процедурные описания шагов тестирования.

EarlGrey также содержит сопоставители, доступные из класса GREYMatchers. В документации рекомендуется использовать элементы пользовательского интерфейса с параметрами доступности. Чтобы идентифицировать элементы пользовательского интерфейса, разработчики могут использовать grey_accessibilityID() или grey_accessibilityLabel() .

 - (void)testBasicSelectionAndAction { [[EarlGrey selectElementWithMatcher::grey_accessibilityID(@"ClickHere")] performAction:grey_tap()]; // Example of long press with EarlGrey matchers - (void)testLongPress { [[EarlGrey selectElementWithMatcher::grey_accessibilityLabel(@"Box")] performAction:grey_longPressWithDuration(0.5f)]; [[EarlGrey selectElementWithMatcher::grey_accessibilityLabel(@"One Long Press")] assertWithMatcher:grey_sufficientlyVisible()]; // Example of multi-select, visible click on items - (void)testCollectionMatchers { id visibleSendButtonMatcher = grey_allOf(grey_accessibilityID(@"Box"), grey_sufficientlyVisible(), nil); [[EarlGrey selectElementWithMatcher:visibleSendButtonMatcher] performAction:grey_tap()]; }

Подобно XCTest, наша реализация радиокнопок не так проста, и кнопки для XCTest должны быть определены как UIElement, поддерживаемые iOS, чтобы обеспечить щелчки и взаимодействие с пользователем.

Заключение

Мы рассмотрели основы приложений React Native и способы их тестирования с использованием различных методов и сред. Это происходит довольно часто, но отраслевые стандарты автоматизации мобильного тестирования на уровне функционального пользовательского интерфейса будут работать с приложениями React Native так же, как и с любыми другими нативными приложениями. Среды автоматизации тестирования, которые мы рассмотрели здесь, широко используются для нативных мобильных приложений, гибридных приложений, мобильного Интернета, а также приложений React Native.

Таким образом, определение языка программирования, на котором построено мобильное приложение, не имеет решающего значения, поскольку оно не окажет никакого влияния на среды автоматизации тестирования, с помощью которых оно может быть протестировано. Как уже говорилось, сегодня доступно множество мощных фреймворков для автоматизации тестирования, с которыми приложения React Native будут работать в виде APK или IPA.

Что вы используете для тестирования приложений React Native? Взвесьте с комментарием ниже!