Comments 10
Спасибо за статью и публикацию фреймворка.
Про укрупнение шагов можете пояснить?
Как, например, на базе шагов
"ввести значение admin в поле login"
"ввести значение admin в поле password"
"нажать кнопку login"
сделать укрупненный шаг
"войти с логином admin и паролем admin"?
Есть примеры?
Рад что смогли заинтересовать.
Пример с созданием укрупненных шагов есть в проекте template.
Вот в этом классе для формирования цикла возврата подключены классы отвечающие за проверку загруженности страницы и за системные нажатия.
Общий процесс формирования укрупненных шагов можно описать как вызовы более мелких.
Добавил пример в проект template
Мы намеренно не выкладывали шаги, которые зависят от приложения с которым работаем т.к в каждом новом проекте подобные шаги будут свои.
Пример с созданием укрупненных шагов есть в проекте template.
Вот в этом классе для формирования цикла возврата подключены классы отвечающие за проверку загруженности страницы и за системные нажатия.
Общий процесс формирования укрупненных шагов можно описать как вызовы более мелких.
Добавил пример в проект template
Мы намеренно не выкладывали шаги, которые зависят от приложения с которым работаем т.к в каждом новом проекте подобные шаги будут свои.
Приветствую! Решали ли вы проблему с разным функционалом iOS и Android приложения? Насколько хорошо получается переиспользовать степы между iOS и Android?
Не до конца понимаю вопрос про разный функционал, скорее про разное поведение. (Если не прав, уточните, пожалуйста, что имели ввиду)
Шаги переиспользовать получается, в пакете steps.general лежат шаги используемые на обоих платформах, в основном там нажатия, заполнения, работы со списками и проверки для этих категорий.
А, например, работа с календарем имеет разное поведение. В этом случае мы создаем по классу в пакетах steps.ios и steps.android, если возможно с одинаковыми bdd-описаниями, и реализуем шаги под платформу.
Шаги переиспользовать получается, в пакете steps.general лежат шаги используемые на обоих платформах, в основном там нажатия, заполнения, работы со списками и проверки для этих категорий.
А, например, работа с календарем имеет разное поведение. В этом случае мы создаем по классу в пакетах steps.ios и steps.android, если возможно с одинаковыми bdd-описаниями, и реализуем шаги под платформу.
Разный функционал можно представить простым примером: Предположим, что в Android версии приложения есть некая Лента последней активности пользователя. Однако, для iOS это еще не было реализовано. Оба приложения именно в таком виде были выпущены в прод.
В таком примере у нас будет сценарий для Android, и не будет сценария для iOS.
Общих сценариев на обе платформы нет, т.к при изменении логики приложения надо будет лезть в код, а мы ставили задачу максимального понижения порога входа для написания этих сценариев.
Простой пример изменения: Приложение переходит на новый дизайн и есть изменения в кнопках, которые нам надо нажимать, скажем раньше был плюсик где-то в углу, со своим id, а теперь большая кнопка «Платежи» и id потерялся по каким-то причинам.
В настоящее время нам для внесения изменений в проект достаточно внести изменение в локаторы одного элемента, а код останется неизменным.
Общих сценариев на обе платформы нет, т.к при изменении логики приложения надо будет лезть в код, а мы ставили задачу максимального понижения порога входа для написания этих сценариев.
Простой пример изменения: Приложение переходит на новый дизайн и есть изменения в кнопках, которые нам надо нажимать, скажем раньше был плюсик где-то в углу, со своим id, а теперь большая кнопка «Платежи» и id потерялся по каким-то причинам.
В настоящее время нам для внесения изменений в проект достаточно внести изменение в локаторы одного элемента, а код останется неизменным.
Сокращение времени тестирования в 8 раз — это довольно-таки хороший результат!
Sign up to leave a comment.
Colibri-ui — наше решение по автоматизации тестирования мобильного приложения