Удаленка для jenkins+selenide+selenoid+allure+docker спецов на 2-3 часа в день. 100% remote! Присоединиться к проекту

Modern automation framework in 2018 / Создаём свой фреймворк в 2018 году

design-patterns
framework
infrastructure
frontend
mobile
webdriver
Теги: #<Tag:0x00007fedbbd87e20> #<Tag:0x00007fedbbd87cb8> #<Tag:0x00007fedbbd87b50> #<Tag:0x00007fedbbd87a10> #<Tag:0x00007fedbbd878d0> #<Tag:0x00007fedbbd87768>

(aino) #1

Коллеги, всем привет!

В последнее время читал несколько статьей про современную веб-разработку:
https://medium.com/tech-tajawal/modern-frontend-developer-in-2018-4c2072fa2bc



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

Допустим, я решил строить свой новый классный и блестящий фреймворк в 2018 году, выбрал любимый язык или пару языков, раннер тестов, CI присмотрел, VCS.
Выяснил что нужны будут тесты для WEBa и Mobile (iOS, Android). Самое время спроектировать фреймворк, который позволит быстро писать и поддерживать тесты.

Вопрос: с чего начать? Какой шаблон проектирования мне стоит использовать в 2018 году? Достаточно ли стандартного PageObject’a? Или нужно смотреть в сторону других подходов, таких как: Page Factory, Screenplay Pattern, Page Element или что-нибудь ещё?! Какой подход к организации тестов позволит мне автоматизировать тесты для фронтенда, написанного с использованием актуальных фреймворков (angular, react, vue.js) и для UI мобильных приложений?

Поделитесь опытом, мыслями, идеями!

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





И много-много других: покороче, подлиннее с комментариями и без. Самое время выяснить - эти статьи всё также актуальны? Или сегодня нужно что-то ещё?


(Ruslan Semerenko) #3

О да, статья про Selenium RC очень актуальна в 2018


(aino) #4

Руслан, может быть что-то конструктивное хочется добавить?


(Павел) #5

Выяснить, какие задачи бизнеса вы собираетесь решать с помощью автоматизации. Автоматизация сама по себе не нужна.

Как только разобрались с задачами, определитесь с языком (Java/Python/C#/JS/Brainfuck/etc). Если приложение пишется на JS, то это совсем не значит что и тестовый фреймворк должен быть на JS.

Решите, кто будет писать и поддерживать код так, чтобы через 6 месяцев ваш фреймворк не превратился в месиво. Если таких людей нету, то лучше не начинать а потратить деньги заказчика на что-то более полезное (лицензии/дополнительные клауды/больше мануал тестировщиков/etc).

См. пункт выше. Вопрос бессмысленный без привязки к задачам, которые вы собираетесь решать.

И да и нет, зависит от сложности вашего приложения.

Работают как по отдельности, так и вместе, дело вкуса.

Не увидел какой-либо пользы в нем. Зачем писать вещи вроде

expect(james.toSee(TodoListItems.Displayed)).eventually.equal(expectedItems);

если можно сразу использовать полноценный BDD фреймворк вроде Cucumber/JBehave и писать нормальные тесты, вместо этих приседаний с псевдо-кодом в BDD стиле?

Не работал с JS фреймворками, но с JVM это решается организацией мультимодульного проекта с Maven/Gradle. Общий код выносится в один модуль, тесты для мобильных девайсов во второй, для фронтенда в третий и т.д.

P.S. универсальная рекомендация - поменьше пишите своих велосипедов, используйте уже готовые опенсорсные.


(Oleksandr Khotemskyi) #6

Стек\язык не принципиален. Нижесказанное в контексте selenium ui functional тестов

  • Время прогона всех тестов на всех конфигурациях === времени прогона самого долгого теста
  • Тесты запускаются на каждый PR (или чаще)
  • Встроены в pipeline и блокируют его при падениях
  • Отчеты\Репорты позволяют смотреть тренд и историю прогонов каждого теста. Содержат логи браузера, логи драйвера, скриншоты\видео, логи тестов, и вменяемые кастомные сообщения об ошибке, тестовые данные.
  • ИМХО: Фреймворк использует качественный OOP подход с разбиением на страницы, компоненты\фрагементы и свои кастомные элементы. Каждый объект тесно связан с кодом компонентом\фрагментом фронтед проекта. При изменении кода фрагмента на фронтенде - мы должны получить максимум апдейтов в своем объекте автоматически.
  • Поддержка максимального количества браузеров и платформ. Pairwise для запуска тестов на разных конфигурациях.
  • Основная масса тестов не использует реальный бекенд, а использует заглушки вместо. end-2-end тесты тоже есть - но как вишенка на торте.
  • Code coverage репорты для фронтенд кода автоматически после прогона. UI (client-side) performance отчеты автоматически после прогона. Потенциально - блокирование pipeline при неудовлетворительных результатах, которые анализируются автоматически.
  • Тестовая ферма (тестовый кластер с платформами\окружениями на которых бегут тесты) - расширяется динамически (autoscaling) и не простаивает без задач.

(Yury) #7

Привет!
Поясни плиз, как вы это делаете в контексте selenium ui functional тестов?


(Oleksandr Khotemskyi) #8

UI стартует уже с моками, или из тестов внедрятся в приложение и заменять http вызовы


(aino) #10

И да и нет, зависит от сложности вашего приложения.

Павел, в каком случае не достаточно PageObject?


(aino) #11

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

Олександр, а можно про это поподробнее?


(aino) #12

@xotabu4 @scormaq коллеги, вернитесь, давайте обсудим))


(Павел) #13

Посмотрите отличный доклад от Николая Алименкова, там он освещает этот и другие вопросы:


(Oleksandr Khotemskyi) #14

Это пока просто хотелки. У меня есть только черновые прототипы такой интеграции с фронтенд компонентами.


(aino) #15

Про интеграцию с фронтом - понятно, а про это можно побольше:

Фреймворк использует качественный OOP подход с разбиением на страницы, компоненты\фрагементы и свои кастомные элементы.

В чём отличие от стандартного PageObject?

Тестовая ферма (тестовый кластер с платформами\окружениями на которых бегут тесты) - расширяется динамически (autoscaling) и не простаивает без задач.

Свои облака создаёте или всё на AWS/Azure/Google cloud?


(Oleksandr Khotemskyi) #16

А ничем. Это не замена, а развитие - page components, html elements, fragments … - это все об одном и том же - инкапсуляция логики взаимодействия со страницей в обьекты\классы

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


(aino) #17

А как на выделенных машинах (своих, не облаках) добиться такого результата? @xotabu4