Pull to refresh

Самопальный фрэймворк Arachnidium для тестирования web и мобильных приложений. Part 2. Немного о настройках

Reading time 4 min
Views 4.4K
И снова всем привет!

По итогам опроса, который я оставил в свой предыдущей статье «Самопальный фрэймворк Arachnidium для тестирования web и мобильных приложений. Get started!» большинство проголосовало «ЗА». Что же, show must go on!

В данной маленькой публикации я расскажу о наработке, позволяющей подготовить настройки для кросс-браузерного тестирования вэб-приложений/кросс-платформенного и просто запуска мобильных приложений для выполнения теста — в рамках описываемого фрэймворка. Сразу скажу, что фича может быть воспринята неоднозначно в силу определенных причин. Часть из них вполне объективные и их я назову в самом конце статьи.

Данный пост как-бы визуализирует главу Configuration моей собственной документации (пока это вики странички на github), которую в ближайшее время предстоит актуализировать. Здесь будет представлен простой пример подготовки настройки, а так же пример того, как я предполагаю использовать свой формат в контексте автоматизации тестов при помощи Selenium и Appium. Статья содержит интересное и наглядное, как мне думается, видео.

План:
— Что за проблему я попробовал решить?
— Простая демонстрация
— Демонстрация на примере кросс-браузерного теста
— Чего не хватает
— Анонс


Обозреваемое решение целиком находится на github.

Поехали!

Что за проблему я попробовал решить?


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

image

Это Suite editor, настройка переменных. Он предлагает
1. Создать переменную
2. Указать ее тип
3. Указать значение по умолчанию
4. Указать локальное значение
5. Если хотите — добавить описание.

Подробнее о 3 и 4. Если отсутствует локальное значение — то применяется значение по умолчанию, иначе оно перекрывается локальным значением.

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

На текущем проекте, где тесты пишутся на Java, я наблюдаю другую картину.
Набор переменных один и тот же, а их значений великое множество.
И все это записано в файлы *.properties.
Каждый файл *.properties хранит в себе 1-несколько наборов значений одних и тех же параметров. Набор параметров один и тот же из файла в файл, значений — частично тоже (в значительной степени).
По-моему — не удобно и избыточно!

Итак. Примерам выше не хватает, на мой взгляд, того, что в ООП называется наследованием/перекрытием.

image

Я решил для описываемой наработки придумать свой способ настройки с блэкджеком и со следующими свойствами:

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


Итак, *.properties как-то отпал. XML тоже (пункт в, имхо — формат избыточен). Я остановился на JSON. Но, пожалуй, это не самый интересный момент.

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


Java:
а) придумать один-несколько классов, позволяющих обращаться к настройке в целом. По моему лучший вариант обращения — указывать группу и нужный параметр. Как к Map'у.
б) придумать один-несколько абстрактных классов, наследники которых могли бы использоваться для облегчения доступа к данным, преобразования хранимых данных в более сложные объекты, если это необходимо.


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

Я предположил, что фича может быть использована под разные проектные нужды. Но по умолчанию — это запуск различных браузеров, мобильных приложений, установка тайм аутов, различных опций Webdriver'a и т.п.

Итак…

Простая демонстрация


В данном видео я демонстрирую способ подготовки настроек и принцип их совместной работы на очень простом примере.



От себя хочу сделать небольшую ремарочку… Перечень типов можно расширить. Полезным было бы расширение до перечислений (ENUM, назовем это так). С объектами прочих классов все сложно. Это и наличие разных вариантов недефолтных конструкторов. Это и предположение, например, что нужно использовать фрэймворки вроде Spring и нужно работать с бинами…

Ниже пример чуть более сложной ситуации.



Демонстрация на примере кросс-браузерного теста


Show time! Ниже я хочу продемонстрировать пример использования фичи для запуска браузеров (тоже самое работает и для мобильных приложений). На этот раз все крайне просто. Пользователь заходит в поисковик Google, что-то набирает — например Hello World Wikipedia — копипаста из тестов, которые я гоняю перед билдами, и смотрит, что Google чего-то нашел. Поехали!



Аналогичные примеры доступны на github:
1
2
3

Чего не хватает.


Объективно, на данный момент не хватает инфраструктуры вокруг этой фичи, не считая запуска Webdriver'а. Что я имею ввиду?

Такие настройки можно использовать в профилях maven. Нужен maven плагин.
Такие настройки могли бы использоваться системами непрерывной интеграции — минимум это Jenkins, TeamCity, другими по мере необходимости.
Такие настройки могли бы использоваться фрэймворками, запускающими тесты — например для параметризации. Поэтому было бы неплохо иметь плагины, листенеры, раннеры и прочие нашлепки для JUnit, TestNG, JBehave и Cucumber JVM.
Раз уж есть какие-то правила, формат и заготовленные наименования групп и настроек, то было бы очень неплохо иметь плагин для IDE (например Eclipce или IDEa), имеющий эргономичный интерфейс, позволяющий настраивать предопределенные группы и значения параметров, а так же создавать свои собственные.

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

Анонс


Надеюсь, материал вам не показался скучным. Я старался как мог.
Я бы хотел сделать еще два топика. В следующем я бы описал по-настоящему интересные (киллер-) фичи, связанные с Webdriver'ом и Page/Screen object'ами. После — чилл аут, где бы я продемонстрировал некоторые экспериментальные наработки, но тоже интересные.
Only registered users can participate in poll. Log in, please.
Но нужно ли?
94.12% да +1 16
11.76% нет -1 2
17 users voted. 10 users abstained.
Tags:
Hubs:
+5
Comments 5
Comments Comments 5

Articles