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

инструменты
, , , , ,
#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 мобильных приложений?

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

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

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

image.jpg1792×1472 413 KB

1 лайк
#3

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

#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. универсальная рекомендация - поменьше пишите своих велосипедов, используйте уже готовые опенсорсные.

4 лайка
#6

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

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

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

#8

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

1 лайк
#10

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

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

#11

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

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

#12

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

#13

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

4 лайка
#14

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

1 лайк
#15

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

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

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

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

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

#16

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

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

#17

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