Авто тестирование мобильных приложений
Мобильное тестирование, автоматизация и тестирование API: С чем нужно уметь работать тестировщику в 2021 году
Специалисты «Рексофт» собрали актуальные инструменты, которые облегчат жизнь тестировщику и помогут быстрее справляться с привычными задачами.
Мобильное тестирование
Мобильное тестирование — одна из самых активно развивающихся сфер из-за быстро растущего рынка мобильных приложений. Разберем, на что нужно обращать внимание при тестировании мобильных приложений и каким инструментарием для этого необходимо владеть.
Начинают тестирование с проверки на соответствие требованиям и дизайну. Речь здесь не только о том, чтобы проверить наличие всех картинок или работоспособность ссылок, а о полноценном UX/UI анализе. Это значит, что тестировщик должен уметь работать с Figma, Zeplin, использовать инструменты проверки интерфейсов вроде Appium Viewer и другие. Также необходимо проработать все возможные маршруты перемещения пользователя по приложению. С этой целью составляют mindmap — диаграмму связей между страницами. Для этого подойдет любой mindmap-продукт — например, Mindomo или xMind.
Чек-лист тестирования мобильных приложений:
Работа приложения в разных режимах: portrait/landscape, split screen.
Прерывания — входящие звонки, СМС, доступ к интернету, предупреждение о низком заряде батареи, внезапное отключение устройства и другие.
Поддержка платежных систем (если присутствуют платежные транзакции).
Соответствие гайдлайнам операционных систем.
Влияние на производительность устройства.
Также необходимо проанализировать сетевой трафик: обрыв сети и слабый интернет, исходящие запросы и полученные ответы. Для этого используют снифферы Charles/Fiddler, Proxyman и другие.
При необходимости выполняют тестирование API. Для этой задачи используют специализированные инструменты: Swagger, Postman, SOAPUI. Они помогают документировать запросы и выполнять их интерактивную проверку. Подробнее их мы рассмотрим дальше.
Для тестирования на различных устройствах используют эмуляторы вроде Genymotion, BlueStacks. Однако успешные тесты на эмуляторе не гарантируют, что приложение будет работать без сбоев на реальных устройствах. Чтобы подключиться к реальным мобильным устройствам и интегрировать туда автотесты, используют фермы BrowserStack, Xamarin или AWS. Либо можно поднять собственную ферму на базе OpenSTF — это позволит всем сотрудникам иметь равный доступ к тестовым устройствам, что особо важно в условиях распределенных команд и удаленной работы.
Для автоматизации UI тестирования мобильных приложений используют Appium, Detox, Ranorex — инструменты автоматизации для запуска сценариев и тестирования приложений на Android или iOS с помощью веб-драйвера. Подробнее инструменты для автоматизации тестирования мы рассмотрим ниже.
Когда ваш проект имеет большое количество автотестов, будет полезно автоматизировать их запуск при каждой сборке нового билда. Чтобы настроить этот процесс, используйте системы CI/CD — Jenkins/TeamCity.
Итоговый набор инструментов мобильного тестировщика:
Тестирование UI/UX: Figma, Zeplin, любой mindmap-like продукт.
Анализ сетевого трафика: Charles/Fiddler, Proxyman.
Тестирование API: Swagger/Postman/SOAPUI.
Автоматизация UI тестирования мобильных приложений: Appium, Detox, Ranorex.
Фермы устройств для тестирования мобильных приложений: BrowserStack, Xamarin, AWS.
Системы CI/CD: Jenkins/TeamCity.
Автоматизация тестирования
Автоматизированное тестирование в ближайшие годы точно не заменит ручное, однако его доля из года в год продолжает расти. Наибольшей популярностью здесь пользуются следующие инструменты.
Платформы для автоматизации
TestComplete — функциональная платформа позволяет создавать автоматизированные тесты для десктопных и веб-приложений, а также приложений под Android и iOS. Тесты могут быть записаны, написаны по сценарию или созданы вручную с помощью операций, управляемых ключевыми словами, и использованы для автоматического воспроизведения и регистрации ошибок. Инструмент поддерживает сценарии на языках Python, JavaScript, VBScript, и C++ Script.
Katalon Studio — решение на основе платформ автоматизации с открытым исходным кодом Selenium и Appium. Имеет специализированный интерфейс IDE для тестирования веб-приложений, API, мобильных и настольных приложений. Может быть интегрирован в CI/CD, совместим с qTest, JIRA, Jenkins и Git.
Инструмент активно развивается от года к году и имеет одно неоспоримое преимущество — минимальный порог вхождения, Некоторые сценарии там можно записать, используя только автоматический рекордер и не выполняя никаких дополнительных действий.
Обратите внимание, что ни одна из платформ не сравнится по функционалу и применимости с полноценной автоматизацией на языке программирования. Если уровень подготовки инженеров позволяет писать тесты, используя среду разработки со всем многообразием приемов и библиотек, то это будет лучшим решением. В этом случае вы не будете ограничены возможностями конкретной платформы.
Open-source фреймворки
Selenium — инструмент для автоматизации действий веб-браузера. В большинстве случаев используется для тестирования web-приложений, но этим не ограничивается. В частности, может быть использован, чтобы решать рутинные задачи администрирования сайта или регулярного получать данные из различных источников.
Selenium имеет огромную поддержку и постоянно совершенствуется. На его основе сделано много других инструментов, упрощающих работу, но не меняющих основу. Он не очень прост в обращении в отличие от его наследников, но все равно имеет самое большое число последователей и рекомендуется к изучению для понимания основ.
Selenide — это обёртка вокруг Selenium WebDriver. Упрощает работу и позволяет сосредоточиться на логике вместо рутины с браузером. Для многих этот инструмент стал спасением: он может выполнять те же функции, что и Selenium, но не требует непосредственной реализации простейших функций в проекте, а поставляется сразу вместе с ними, что в разы ускоряет стартовый этап взаимодействия. Также имеет несколько полезных фич: встроенные скриншоты, прокси, логирование, удобная интеграцию с удаленным выполнением тестов.
Allure — инструмент от Яндекса, первый по популярности в области визуализации отчетности автотестов. Allure строит графики, отображает названия с тестов, их шаги, прикрепленные файлы и скриншоты. Очень удобен и прост в подключении, умеет работать из коробки с основными фреймворками для автотестирования, такими как Junit или Testng.
Junit — один из самых популярных фреймворков для автотестирования в Java-среде. Позволяет работать как с модульными, так и с любыми функциональными тестами. Junit прост в использовании: в отличие от своего ближайшего конкурента Testng не требует сложной настройки, поддерживает многопоточность и тестирование на основе данных, а также интегрирован со сборщиками (Maven, Gradle).
Selenoid — удобный инструмент для удаленного и параллельного запуска тестов. Использует докер, который обеспечивает хорошую изолированность сессий браузера и быстродействие.
Selenoid можно легко поставить как на локальную машину, так и на виртуалку. Следить за выполнением тестов можно через браузер, обратившись к Selenoid UI. Инструмент отображает как загрузку контейнеров, так и непосредственно выполнение теста.
Selenoid позволяет с легкостью запускать тесты на любом из популярных браузеров, имеет собственные средства для создания скриншотов с сессии и записи видео. Для систем, построенных на Kubernetes или Openshift, используется Moon — инструмент от той же организации, но обладающий расширенным функционалом для интеграции.
Appium — инструмент автоматизации тестирования мобильных веб-приложений и гибридных приложений на Android или iOS с помощью веб-драйвера. Обладает открытым исходным кодом и позволяет писать сценарии, используя все языки, в которых есть библиотеки Selenium, так как работает на основе Selenium Webdriver. Благодаря кроссплатформенности и возрастающему интересу к мобильной автоматизации пользуется все большей популярностью.
Системы CI/CD
Jenkins — система с открытым исходным кодом на Java, предназначенная для обеспечения процесса непрерывной интеграции программного обеспечения. Это бесплатный инструмент, который включает тысячи постоянно обновляющихся плагинов. Удобен для автоматизации функционального тестирования как API, так и UI, потому что содержит плагин для работы с Allure, умеет хранить отчетность и отображать тренды.
Jenkins позволяет отслеживать ход тестирования на временных графиках. Параметризировать запуски, к примеру, настроить запуск на определенное время или сформировать письмо с кратким отчетом по указанному адресу после выполнения.
GitLab — в первую очередь, это система управления репозиториями программного кода. Репозитории включают систему контроля версий для размещения различных цепочек разработки и веток. Позволяют разработчикам проверять код и откатываться к стабильной версии софта в случае непредвиденных проблем. Все это полезно также и при автоматизации тестирования и использовании систем непрерывной интеграции. Сам GitLab также является CI/CD системой, но не такой распространенной, как Jenkins или Teamcity.
Тестирование API
Интерес к тестированию API стабильно растет в последние несколько лет. Это важный компонент в процессе CI/CD, необходимый для успешного развертывания ПО. Приводим основные инструменты, которыми необходимо владеть для тестирования API.
SOAPUI — консольный инструмент для тестирования API, который помогает легко тестировать API REST и SOAP, а также web-сервисы. Инструмент позволяет получить полный исходный документ и встроить предпочтительный набор функций.
Postman — отличный выбор для API тестирования для тех, кто не желает иметь дела с кодировками в интегрированной среде разработки, используя тот же язык программирования, что и разработчик. Инструмент позволяет создавать запросы REST, SOAP и GraphQL. Поддерживает множество протоколов авторизации и управление сертификатами.
REST-assured — DSL для тестирования REST-сервисов, который встраивается в тесты на Java. Это решение появилось более девяти лет назад и стало популярным из-за своей простоты и удобного функционала.
Инструментов, которые позволяют писать API тесты в среде разработки несколько, но исторически REST-assured является самым популярным для функционального тестирования. Его используют для тестирования множества систем, это полноценный инструмент с множеством протоколов и опций, позволяющий преодолеть проблемы, связанные с авторизациями, токенами, электронными подписями и другими возникающими сложностями.
Из минусов можно назвать плохую работу с параллельными запросами и не самый удобный инструмент проверок ответов от сервера. Но здесь Junit в помощь.
Swagger — фреймворк с открытым исходным кодом, позволяющий разработчикам создавать документацию для REST API. Тестировщики могут использовать его как примеры, тут сразу видно, что за эндпоинт был сделан, какого типа, по какому url. Часто представлены примеры заполнения запроса, ответа и возможных кодов ответа на запрос.
На этом пока все. Расскажите в комментариях, какие инструменты для тестирования используете вы. Будем рады вашим дополнениям.
Автоматизация тестирования мобильных приложений с Appium
Автоматизация тестирования – тема не новая, однако мобильная автоматизация стала трендом относительно недавно. И востребованность сервиса постоянно растет. Вызвано это тем, что мобильные приложения становятся более функциональными, перенимая роль настольных ПК.
Однако растущая функциональность и частые обновления не всегда позволяют ручному тестировщику покрыть все кейсы регрессии за короткий промежуток времени. И вот тут на помощь приходит автоматизация.
Преимущества мобильной автоматизации
Преимущества автоматизации тестирования мобильных приложений во многом совпадают с плюсами автоматизированного тестирования веб-приложений:
Преимущества весомые, но и минусов хватает:
Выбор подхода и инструментов для автоматизации
С автоматизацией тестирования веб-приложений все более-менее ясно: Selenium WebDriver – самый популярный инструмент на рынке, который освоили все профессиональные команды по тестированию. А вот при автоматизации тестирования мобильных приложений однозначного ответа при выборе инструмента нет.
Однако главный вопрос касается не выбора инструмента, а подхода. Именно выбранный подход предопределит инструмент для последующей разработки автотестов.
При автоматизации тестирования мобильных приложений можно использовать один из следующих подходов:
Первый способ прост и сводится к записи всех действий пользователя (тестировщика) в приложении. После записи действий инструмент генерирует понятный для него код и создает автотесты.
Плюсы: быстрая реализация, не требуется знаний программирования;
Минус: малейшие изменения в приложении потребуют создать новый автотест.
Второй подход – Screen Object – паттерн, предназначенный для организации архитектуры автотестов в виде взаимодействия экранов приложения.
Screen Object моделирует экраны (или страницы) тестируемого приложения в качестве объектов в коде. В результате мы получаем набор классов, каждый из которых отвечает за работу с отдельным экраном приложения.
Плюсы:
Минусы:
Конечно, для полного и качественного тестирования продукта рекомендуется использовать второй подход. Если же ваши тестировщики не владеют ни одним языком программирования, советуем рассмотреть вариант привлечения сторонней команды.
Итак. Подход выбран. Теперь время выбрать инструмент.
Инструментов для автоматизации много. На рисунке ниже изображены самые популярные из них. Но важно отметить, что некоторые из них подходят для приложений, написанных на конкретном языке программирования. Например, Xamarin (левый нижний угол) подходит только для приложений на С#. Некоторые – стоят немалых денег (например, утилита Ranorex).
Поэтому очень важно до начала внедрения автоматизации взвесить все «за» и «против» не только самого процесса, но и инструмента для ее реализации.
Команда a1qa рекомендует использовать фреймворк Appium.
Appium — инструмент для автоматизации тестирования на iOS и Android
Appium — это бесплатный кроссплатформенный инструмент с открытым исходным кодом, который помогает автоматизировать приложения как для Android, так и для iOS. Является одним из самых широко используемых инструментов для создания автоматических тестов для смартфонов и планшетов.
Несомненными преимуществами Appium является простота в использовании, а также поддержка многих языков программирования: Java, Ruby, Python, C#, PHP.
Прежде чем начинать работать с Appium, необходимо настроить окружение из следующих компонентов:
Поясним. Сначала устанавливаем Appium Server, который понадобится для связи исходного кода теста с реальным устройством или эмулятором.
Затем устанавливаем Xcode, а также Android Studio вместе с Android SDK. Это необходимо для того, чтобы позже при необходимости установить необходимые эмуляторы.
Выбрав язык программирования, на котором будут разрабатываться тесты, необходимо установить соответствующий набор библиотек. Например, для написания автотестов для Android и iOS с выбранным языком программирования Java потребуется Java Development Kit.
Что использовать: настоящие устройства или эмуляторы?
Тестировать на эмуляторах или на реальных устройствах – один из главных вопросов при тестировании мобильных приложений. Стоит отметить, что работа с эмулятором создает дополнительную нагрузку на машину, что замедляет выполнение теста.
К тому же результаты тестов на эмуляторах не всегда отвечают действительности. Нередко случается, что на эмуляторе все тесты пройдены, а при запуске на реальном устройстве, система блокирует работу из соображений безопасности, и тест не будет пройден.
Учитывая это, команда автоматизаторов a1qa настоятельно рекомендует проводить тестирование на реальных устройствах.
Вместо заключения
Если вы решили, что автоматизация мобильного тестирования – это то, что нужно на вашем проекте, убедитесь, что выбранный подход и инструменты отвечают всем вашим требованиям. В таком случае вы сможете достигнуть главной цели – выпустить на рынок качественный продукт в установленные сроки.
Автоматизация тестирования мобильных приложений. Часть 1: проверки, модули и базовые действия
Приложениями Badoo и Bumble пользуются миллионы людей по всему миру, и мы стремимся доставлять им новую функциональность как можно быстрее. Но важно, чтобы высокий темп нашей работы не сказывался негативно на качестве работы приложений. В этой статье мы расскажем о роли автоматизации в наших процессах и поделимся практиками, которые позволяют быстро писать стабильные тесты.
Меня зовут Дмитрий Макаренко, я Mobile QA Engineer в Badoo и Bumble: занимаюсь тестированием новой функциональности вручную и покрытием её автотестами. В подготовке этой статьи мне помогал коллега Виктор Короневич: вместе мы делали доклад на конференции Heisenbug.
Примеры, которые мы разберём в этой статье, актуальны как для тех, кто только начинает внедрять автоматизацию тестирования в своём проекте, так и для тех, кто уже активно её использует.
Начнём с короткого рассказа о процессах тестирования и фреймворке автоматизации в нашей компании.
Место автоматизации в наших процессах
Раньше за тестирование новой функциональности у нас отвечали команды мобильного тестирования: отдельно iOS- и Android-, и проводили тесты они вручную. А создание и поддержка end-to-end-тестов (именно о них и пойдёт речь в этой статье) находились в зоне ответственности выделенной команды автоматизации. При этом ручным тестированием занимались около 30 человек, а автоматизацией — десять. Последним, конечно, было сложно всё успевать: улучшать фреймворк, инфраструктуру и автоматизировать то, что тестируют руками больше 20 человек.
За последние два года процессы сильно изменились. Сегодня релиз новой функциональности невозможен без покрытия её тестами разных уровней, в том числе end-to-end-тестами (про это можно подробнее узнать из доклада Катерины Спринсян). Их теперь у нас создают и поддерживают команды мобильного тестирования. А команда автоматизации уделяет больше времени работе с фреймворком и инфраструктурой.
Вместе с изменением процессов изменились и требования к автоматизации. Нам важно иметь возможность писать тесты быстро, чтобы не задерживать релизы. При этом тесты должны быть стабильными. Мы постоянно стремимся улучшать эти показатели, и со временем у нас сложился набор практик, которые нам в этом помогают.
Прежде чем перейти к их описанию, скажу пару слов о нашем фреймворке, чтобы контекст примеров был понятен.
Фреймворк
Наши приложения Badoo и Bumble — нативные. То есть Android-приложения разрабатываются одной командой на Kotlin и Java, а iOS- — другой командой на Swift и Objective C.
При этом функциональность Android- и iOS-приложений во многом схожа. Именно поэтому одним из главных критериев выбора фреймворка автоматизации для нас была возможность переиспользования сценариев. Руководствуясь этим, мы выбрали кросс-платформенный фреймворк для автоматизации Calabash. Мы пишем тесты на Ruby, а для написания сценариев пользуемся фреймворком Cucumber.
Неважно, какой фреймворк вы используете. Мы обобщили наши рекомендации, чтобы вы тоже могли их применять.
Практика №1. Где и как писать проверки
Чтобы понять, где можно писать проверки, рассмотрим структуру тестов. Она состоит из трёх уровней.
Первый уровень – сценарий. Здесь сам тест написан на человекочитаемом языке Gherkin, описаны все необходимые действия и проверки.
Второй уровень — определение шагов. В соответствии с действиями или проверками с первого уровня ставится Ruby-код, который их выполняет.
Третий уровень — уровень страниц. Здесь описываются экраны нашего приложения и действия, которые мы можем на них совершить — например, получить текст выбранного элемента, нажать на выбранную кнопку и т. д.
Переходим к практике. У нас есть задача: создать проверку какого-либо элемента. Это слишком общая формулировка, поэтому рассмотрим конкретный пример. Это будет проверка сообщения о пропущенном видеозвонке.
Диалог с тестовым пользователем
Начнём со сценария для проверки этого сообщения.
В тексте сценария вы можете заметить аббревиатуру QAAPI. Это API, с помощью которого мы можем менять состояние системы во время тестирования. Например, можно отправлять сообщения или загружать фото профиля тестовым пользователям, используя обычные клиент-серверные запросы. Более подробно про QAAPI мы рассказывали в этой статье и докладе.
Сфокусируемся на шаге для проверки сообщения (последний шаг в примере кода).
Определим, что нам необходимо проверить. Это текст сообщения и кнопка «Перезвонить». Разберём первый возможный подход.
В этом примере на уровне определения шагов мы создаём объект класса ChatPage и вызываем метод await для ожидания загрузки нужного экрана. Потом вызываем метод verify_missed_video_call, чтобы проверить отображение необходимых элементов.
На уровне страницы реализация этого метода выглядит следующим образом. Сначала мы формируем ожидаемый результат лексемы. Его мы берём из статического метода, объявленного в модуле CallLexemes, используя class Диалог с тестовым пользователем
Зону диалога мы разделили на модули поменьше, например для разных типов сообщений: текстовых, аудио, GIF-картинок и фото.
Диалог с тестовым пользователем
Модуль поля ввода также состоит из более мелких модулей, таких как поля для отправки фотографий, текста, GIF-картинок и аудиосообщений.
Диалог с тестовым пользователем
После этого мы создали структуру модулей, подобную той, которую вы видите на скриншоте ниже, для Android и для iOS.
После этого нам стало легче создать классы страниц чата в обоих приложениях. По сути, единственное различие заключается в использовании разных базовых страниц, потому что у приложений они немного отличаются.
Теперь мы просто подключаем к странице каждого приложения необходимые модули. Причём речь идёт только об актуальных для приложения модулей. В Badoo, например, это может быть сообщение о подарке, которого нет в Bumble:
Зато в Bumble есть другой тип сообщений, которого нет в Badoo, — реакции:
Наличие такого компонента позволит нам создать страницу чата в любом другом приложении, если оно появится в нашей компании, буквально за пару минут.
Для обоих приложений мы также используем одни и те же шаги. Здесь мы возвращаемся к методам получения текста сообщения о пропущенном видеозвонке и кнопки «Перезвонить». Они находятся в модуле для типа сообщения о видеозвонке.
Этот модуль подключается как для Bumble, так и для Badoo. То есть он написан один раз для каждой из платформ, а проверить сообщение в четырёх наших приложениях (Badoo для iOS и Android и Bumble для iOS и Android) можно с использованием всего одного шага. Так что написать новые тесты для проверки чата в разных приложениях не составляет большого труда.
Мы создаём подобные компоненты и в тех случаях, когда нам не требуется их переиспользовать в разных приложениях, например для экранов с большим количеством UI-элементов. Такой подход в одном приложении позволяет избежать появления в коде так называемых God objects (больше информации здесь и здесь) классов с большим количеством свойств и методов. Поддерживать разбитые на модули страницы гораздо проще, так же как расширять их с появлением новой функциональности.
Подводя итоги этого примера, отметим, что использование компонентов помогает нам:
создавать тесты для разных приложений, используя уже существующие шаги, и экономить на этом много времени;
поддерживать и расширять классы страниц для экранов с большим количеством UI-элементов
Обобщённая рекомендация: для объектов с большим количеством свойств и методов создавать компоненты, состоящие из логически разделённых модулей.
Практика №3. Шаги для базовых действий
Начнём разбирать новый пример с того, что обозначим, какие действия мы считаем базовыми. Это, например, ожидание открытия страницы, верификация страницы, закрытие страницы или переход назад с какой-либо страницы. Мы называем их базовыми, потому что они актуальны практически для любой страницы наших приложений.
Задача, решение которой мы будем рассматривать: реализовать базовые действия для разных страниц.
Представим ситуацию: два тестировщика создали шаги для ожидания открытия страниц чата и профиля:
Мы видим здесь следующие проблемы:
шаги называются немного по-разному, поэтому их сложно будет найти, когда нам понадобится использовать их в новых сценариях;
реализация шагов отличается только классами объектов: ChatPage и OwnProfile. Учитывая, что экранов в наших приложениях намного больше, чем два, создание разных шагов для ожидания открытия каждого из них приведёт к дубликации большого количества кода.
Рассмотрим ещё пример с реализацией шагов для перехода назад с какой-либо страницы:
Тут можно заметить ещё одну проблему: на страницах появились методы (tap_back, go_back, press_back), которые отвечают за одно и то же действие, но называются по-разному. Это произошло потому, что разные люди добавили их в разные места репозитория.
Таким образом, общая проблема этих примеров — дубликация кода, которая существенно замедляет разработку тестов. Мы видим дублирование как в самих шагах, так и в реализации действий на страницах. Это затрудняет переиспользование шагов для базовых действий в разных тестах, так как запомнить все возможные вариации таких шагов практически невозможно.
Как решить эту проблему? Перейдём от простого подхода к более сложному, общему. Мы можем создать объект класса страницы, используя строку из параметра шага. Для этого мы сделали метод page_object_by.
Реализация метода page_object_by выглядит следующим образом:
Мы формируем имя класса из названия страницы, переданного в шаги. Потом, если у нас такой класс описан, то возвращаем объект этого класса. В противном случае — выбрасываем ошибку.
Таким образом, для ожидания открытия любой страницы нам нужно написать всего один шаг. Аналогичный подход мы используем и для всех остальных базовых действий. И это сильно упрощает разработку.
От дубликации методов для базовых действий на страницах мы также избавились, выделив общие методы, например press_back.
Реализация этого метода находится на страницах AndroidBumbleBase, IOSBumbleBase, AndroidBadooBase и IOSBadooBase, от которых наследуются классы остальных страниц в наших тестах. Стоит отметить, что это не совсем правильно. При таком подходе страницы, на которых нет кнопки «Назад», могут использовать метод нажатия на эту кнопку. Правильнее было бы выделить нажатие на кнопку «Назад» в отдельный модуль, например Navigation::Back, и добавить его на все необходимые страницы. Но мы не использовали подобный модуль, потому что нам пришлось бы добавлять его практически на все страницы в нашем проекте, — мы решили немного упростить себе жизнь.
Итак, в контексте этого примера мы рекомендуем:
создавать общие шаги для базовых действий;
создавать общие методы для реализации базовых действий на страницах (переход назад и т. д.).
В прошлом разделе мы рекомендовали создавать модули и переиспользовать их на страницах. А здесь говорим, что надо создавать методы на страницах. Может показаться, что мы немного противоречим сами себе. Но это не так.
Если у вас действительно много методов на странице или если вам нужно переиспользовать код лишь на некоторых страницах, имеет смысл выделить модули и добавить их на необходимые страницы.
Если же у вас есть действие, актуальное для всех страниц, следует выделить его в отдельный метод и определить в классе, являющемся основой для всех страниц в ваших тестах.
Обобщённая рекомендация: если у вас много однотипного кода, выделяйте общие методы.
Эта рекомендация может показаться очевидной, но мы хотим отметить важность её применения. Напомню, что у нас около 40 человек активно занимаются разработкой end-to-end-тестов. Нам было важно с самого начала выбрать правильный подход, чтобы избежать рефакторинга огромного количества однотипных шагов и методов в будущем.
Что мы узнали
Мы рассмотрели три примера решения различных задач, возникающих при создании автотестов. На их основании мы сформулировали следующие обобщенные рекомендации:
выделяйте общие методы для переиспользования однотипного кода — как в шагах, так и в методах на страницах;
создавайте проверки на самом высоком уровне — там, где вы пишете тело теста;
делайте объект тестирования простым;
создавайте компоненты, состоящие из логически разделённых модулей, для объектов с большим количеством свойств и методов.
Возможно, эти советы кому-то покажутся очевидными. Но мы хотим обратить ваше внимание на то, что применять их можно (и нужно) в разных ситуациях.
Во второй части статьи мы разберём ещё четыре примера решения других задач, дополним список наших рекомендаций и поделимся доступом к тестовому проекту со всеми практиками. Оставайтесь с нами!