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

1. Об авторе Вилле-Вейкко Хелппи (Ville-Veikko Helppi) является техническим менеджером по продуктам...
2. Основная архитектура React Native Apps
3. Автоматизация тестирования на разных уровнях: модульный, интеграционный, компонентный и функциональный
4. Модульное тестирование с шуткой и жасмином
5. Интеграционное тестирование
6. Использование функциональных сред автоматизации тестирования с собственными приложениями React
7. Appium
8. Кальян
9. Robotium и ExtSolo (Android)
10. Эспрессо (Android)
11. XCTest и KIF (iOS)
12. ЭрлГрей (iOS)
13. Заключение

Об авторе

Вилле-Вейкко Хелппи (Ville-Veikko Helppi) является техническим менеджером по продуктам в Bitbar Technologies и управляет популярным семейством продуктов Testdroid, используемых для создания мобильных приложений и… Подробнее о Вилле-Вейкко…

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

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

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

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

Увеличение мобильных платформ и фрагментации устройств. ( Посмотреть большую версию )

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

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

Основная архитектура React Native Apps

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

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

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

Реагируйте на процесс разработки в Android и iOS. (Образ: Тестирование мобильных приложений ) ( Посмотреть большую версию )

Ключевым моментом в React Native является то, что он приносит Реагировать на модель программирования на мобильные приложения, разработка и тестирование. На самом деле он не работает непосредственно как кроссплатформенный инструмент или инфраструктура, но ускоряет тенденцию создания мобильных приложений на этой новой платформе. И это один из краеугольных камней того, что делает 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. (Образ: Тестирование мобильных приложений ) ( Посмотреть большую версию )

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

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

Модульное тестирование с шуткой и жасмином

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

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

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

description ("Player", function () {var player; var song; beforeEach (function () {player = new Player (); song = new Song ();}); оно ("должно иметь возможность воспроизводить песню") , function () {player.play (song); ожидаемо (player.currentlyPlayingSong) .toEqual (song); // демонстрирует использование настраиваемого сопоставления ожидающего (проигрывателя) .toBePlaying (song);}); description ("когда песня имеет был приостановлен ", function () {beforeEach (function () {player.play (song); player.pause ();}); it (" должен указывать, что песня приостановлена ​​"), function () {Ожидается (player.isPlaying ) .toBeFalsy (); // демонстрирует использование 'not' с ожидаемым совпадением (player) .not.toBePlaying (song);}); it ("должно быть возможно возобновить", function () {player.resume (); Ожидаем (player.isPlaying) .toBeTruthy (); Ожидаем (player.currentlyPlayingSong) .toEqual (song);});}); // демонстрирует использование шпионов для перехвата и проверки метода, вызывающего его ("сообщает текущему «Песня, сделал ли пользователь ее любимой», function () {spyOn (song, 'persistFavoriteStatus'); player.play (song); player.makeFavori т.е (); ожидать (song.persistFavoriteStatus) .toHaveBeenCalledWith (истина); }); // демонстрирует использование ожидаемых исключений description ("# resume", function () {it ("должно выдать исключение, если песня уже воспроизводится"), function () {player.play (song); ожидаемо (function () {player .resume ();}). toThrow («песня уже играет»);});}); });

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

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

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

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

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

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

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

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

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

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

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

Различные инфраструктуры автоматизации тестирования для функционального тестирования пользовательского интерфейса. (Образ: Testdroid ) ( Посмотреть большую версию )

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

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

<Radio onSelect = {this.onSelect.bind (this)} defaultSelect = {this.state.optionSelected - 1}> <Option color = "black" selectedColor = "# 000000"> <Title title = "First option" description = "Первый переключатель" /> </ Option> <Option color = "black" selectedColor = "# 000000"> <Item title = "Второй параметр" description = "Второй переключатель" /> </ Option> <Option color = "black" selectedColor = "# 000000"> <Item title = "Third option" description = "Третий переключатель" /> </ Option> </ Radio>

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

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

Appium

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

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

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

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

. Driver.findElement (By.id ( "com.example.app:id/radio0")) нажмите (); . Driver.findElement (By.id ( "com.example.app:id/radio1")) нажмите (); . Driver.findElement (By.id ( "com.example.app:id/radio2")) нажмите (); . Driver.findElement (By.id ( "com.example.app:id/editText1")) нажмите (); driver.findElement (By.id ("com.example.app:id/editText1")). sendKeys ("Простой тест"); . Driver.findElement (By.name ( "Ответ")) нажмите (); // или, например, так: driver.findElement (By.id ("com.example.app:id/button1")). click ();

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

Как Appium работает на Android и iOS. (Образ: Testdroid ) ( Посмотреть большую версию )

В 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 написаны на Огурец , Идея использования такого рода языка для тестов удивительна: сам тест похож на спецификацию, и все тесты просты и легки для чтения, но выполняются системой автоматизации.

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

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

Калебас на Android и iOS. (Образ: Testdroid ) ( Посмотреть большую версию )

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

Особенности Calabash, сценарии и шаги. (Образ: Testdroid ) ( Посмотреть большую версию )

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

Функция: Ответить на вопрос. Сценарий: Как действительный пользователь, я хочу ответить на вопрос приложения, я жду текст «Как лучше всего протестировать приложение на сотне устройств?» Затем я нажимаю кнопку-переключатель 0 Затем нажимаю кнопку-переключатель 1 Затем нажимаю кнопку-переключатель 2 Затем я вводю текст «Простой тест» в поле с идентификатором «editText1» Затем нажимаю вид с идентификатором «Кнопка1»

Шаги обычно начинаются с одного из указанных ключевых слов, затем, когда и или, но. Тем не менее, они не должны; они могут использовать * вместо этого.

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

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

$ gem install calabash-android $ gem установить calabash-огурец

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

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

Robotium и 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"), "Простой тест"); solo.clickOnView (solo.findViewById ( "com.example.app:id/button1"));

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

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

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

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

Эспрессо (Android)

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

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

// Идентификатор R класса для переключателей onView (withId (R.id.radio0)). Execute (click ()); OnView (withId (R.id.radio1)) выполняют (нажмите ()). OnView (withId (R.id.radio2)) выполняют (нажмите ()). OnView (withId (R.id.EditText1)) выполняют (нажмите ()). // Вместо R мы используем getIdentifier onView (withId (getInstrumentation (). GetTargetContext (). GetResources () .getIdentifier ("com.example.app:id/EditText1", null, null))). Execute ((typeText) («Простой тест»))); onView (withId (getInstrumentation (). getTargetContext (). getResources () .getIdentifier ("com.example.app:id/Button1", null, null))). execute (click ());

Espresso имеет свои плюсы и минусы, и благодаря легкому 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.

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

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

- (void) testClicksOnRadioButtons {[tester tapViewWithAccessibilityLabel: @ ”Radio1”]; [тестер tapViewWithAccessibilityLabel: @ ”Radio2”]; [тестер tapViewWithAccessibilityLabel: @ ”Radio3”]; [tester enterText: @ ”Simple Test” intoViewWithAccessibilityLabel: @ ”editText1”]; [тестер tapViewWithAccessibilityLabel: @ ”Ответить”]; }

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

testClicksOnRadioButtons () {let app = XCUIApplication () app.radiobutton [0] .tap () app.radiobutton [1] .tap () app.radiobutton [2] .tap () app.staticTexts [«Простой тест»] 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")] executeAction: grey_tap ()]; // Пример долгого нажатия с соответствиями EarlGrey - (void) testLongPress {[[EarlGrey selectElementWithMatcher :: grey_accessibilityLabel (@ "Box")] executeAction: grey_longPressWithDuration (0.5f)]; [[EarlGrey selectElementWithMatcher :: grey_accessibilityLabel (@ "Одно долгое нажатие")] assertWithMatcher: grey_sufficientlyVisible ()]; // Пример множественного выбора, видимого щелчка по элементам - (void) testCollectionMatchers {id visibleSendButtonMatcher = grey_allOf (grey_accessibilityID (@ "Box"), grey_sufficientlyVisible (), nil); [[EarlGrey selectElementWithMatcher: visibleSendButtonMatcher] executeAction: grey_tap ()]; }

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

Заключение

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

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

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

Похожие

Комментарии