Тестирование пользовательского интерфейса Android и iOS с помощью Calabash

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

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

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

Что такое UI-тестирование?

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

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

«Звучит потрясающе», — скажете вы, но как вы сделаете это для своего приложения для Android или iOS?

Фреймворки тестирования пользовательского интерфейса для Android и iOS

Если вы читали официальную документацию для Android и iOS, они предлагают вам писать и запускать тесты пользовательского интерфейса в их официальных IDE. Для Android это Android Studio, а для iOS — Xcode.

Официальная документация даже рекомендует конкретные фреймворки для тестирования. Официальная документация Android охватывает некоторые темы, касающиеся Espresso, среды тестирования пользовательского интерфейса Android. Точно так же Apple предлагает использовать фреймворк XCTest.

И если вы собираетесь серьезно работать над тестами пользовательского интерфейса, вы можете следовать этим советам, что имеет смысл, поскольку Espresso поддерживается Google и является частью репозитория поддержки Android. Очень вероятно, что Espresso будет поддерживать все новые функции, которые Google представит для Android в будущем. То же самое можно сказать и о фреймворке XCTest для iOS.

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

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

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

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

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

Знакомьтесь, Калабаш.

Calabash: автоматизированный приемочный тест для мобильных приложений

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

Эта среда тестирования с открытым исходным кодом, разработанная и поддерживаемая командой Xamarin, работает как для Android, так и для iOS. Он позволяет писать и выполнять автоматизированные приемочные тесты для мобильных приложений.

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

Calabash может взаимодействовать с вашим приложением, как Espresso или XCTest. Однако то, что делает Calabash отличным выбором, так это поддержка Cucumber.

Cucumber — это инструмент, который может запускать автоматические тесты, написанные на простом английском языке (при желании вы можете настроить его для использования любого другого простого языка). Таким образом, для написания автоматизированных тестов на Cucumber тестировщику не нужно знать Java, Objective-C или любой другой язык программирования.

Что заставляет Калабаш тикать?

Фреймворк Calabash состоит из библиотек, которые могут взаимодействовать с приложениями для Android и iOS. Его можно запустить на реальных устройствах. Таким образом, он может делать то, что тестер делает вручную.

На GitHub есть два разных проекта, которые делают Calabash возможным:

• Калабаш-андроид - для Android

• calabash-ios — для iOS

Calabash может работать с любой тестовой средой на основе Ruby. В этой статье мы рассмотрим Cucumber — самый популярный и удобный способ написания тестов для Calabash.

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

Затем установите Calabash для вашей любимой платформы, следуя приведенным выше ссылкам GitHub.

Пишем свой первый тест на Calabash

Написание тестов на Calabash довольно просто. Давайте посмотрим, как выглядит простой тест для iOS-приложения:

 Feature: User Login Scenario: Unsuccessful user login Given the app has launched Then I wait for the "Login" button to appear When I enter "tstuser" into the "Username" field And I enter "qwerty" into the "Password" field And I touch "Login" Then I should see "Username you entered is incorrect" Scenario: Successful user login Given the app has launched Then I wait for the "Login" button to appear When I enter "testeruser" into the "Username" field And I enter "qwerty" into the "Password" field And I touch "Login" Then I should see "Hey testeruser!"

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

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

Любой, кто знаком с разработкой, управляемой поведением (BDD), уже знаком с этим.

Как работает калабас?

Чтобы увидеть, что происходит за шагами, которые использует тестер, вы можете открыть проект на GitHub и проверить следующий файл:

 calabash-cucumber/features/step_definitions/calabash_steps.rb

Давайте посмотрим определение следующего шага:

 When I enter "testeruser" into the "Username" field

 Then /^I enter "([^\"]*)" into the "([^\"]*)" field$/ do |text_to_type, field_name| touch("textField marked: '#{field_name}'") wait_for_keyboard keyboard_enter_text text_to_type sleep(STEP_PAUSE) end

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

Первым словом шага может быть «Дано», «Когда», «Тогда», «И» или «Но». Неважно, какое ключевое слово вы будете использовать. Вы можете использовать любой из них, чтобы сделать историю более понятной.

Как добавить пользовательские шаги

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

Например, если тестировщику необходимо получить доступ к полю ввода по заполнителю, а не по имени поля:

 Then /^I enter "([^\"]*)" into the field with placeholder "([^\"]*)"$/ do |text_to_type, placeholder| touch("textField placeholder:'#{placeholder}'") wait_for_keyboard() keyboard_enter_text text_to_type sleep(STEP_PAUSE) end

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

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

Вы можете найти функции Ruby, которые вы можете использовать, здесь:

http://www.rubydoc.info/gems/calabash-cucumber/Calabash/Cucumber

Облако тестирования Xamarin

Есть еще одна проблема при тестировании мобильных приложений. Вы должны протестировать их на как можно большем количестве устройств, потому что есть так много устройств и так много версий ОС.

В этом очень помогает Xamarin Test Cloud. В облаке около 2000 реальных устройств, и хорошая новость заключается в том, что оно поддерживает тесты Calabash.

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

Начать писать UI-тесты

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