Выглядит так, как будто она стремительно фонтанирует и развивается, соответственно, автоматизация тестирования не должна отставать.
Допустим, я решил строить свой новый классный и блестящий фреймворк в 2018 году, выбрал любимый язык или пару языков, раннер тестов, CI присмотрел, VCS.
Выяснил что нужны будут тесты для WEBa и Mobile (iOS, Android). Самое время спроектировать фреймворк, который позволит быстро писать и поддерживать тесты.
Вопрос: с чего начать? Какой шаблон проектирования мне стоит использовать в 2018 году? Достаточно ли стандартного PageObject’a? Или нужно смотреть в сторону других подходов, таких как: Page Factory, Screenplay Pattern, Page Element или что-нибудь ещё?! Какой подход к организации тестов позволит мне автоматизировать тесты для фронтенда, написанного с использованием актуальных фреймворков (angular, react, vue.js) и для UI мобильных приложений?
Поделитесь опытом, мыслями, идеями!
Разумеется, здесь на сайте большое количество тем посвящено теме фреймворков, архитектуры, шаблонов проектирования. Как разработки своего инструмента, так и использовании существующего.
Например, есть фундаментальные статьи:
И много-много других: покороче, подлиннее с комментариями и без. Самое время выяснить - эти статьи всё также актуальны? Или сегодня нужно что-то ещё?
Выяснить, какие задачи бизнеса вы собираетесь решать с помощью автоматизации. Автоматизация сама по себе не нужна.
Как только разобрались с задачами, определитесь с языком (Java/Python/C#/JS/Brainfuck/etc). Если приложение пишется на JS, то это совсем не значит что и тестовый фреймворк должен быть на JS.
Решите, кто будет писать и поддерживать код так, чтобы через 6 месяцев ваш фреймворк не превратился в месиво. Если таких людей нету, то лучше не начинать а потратить деньги заказчика на что-то более полезное (лицензии/дополнительные клауды/больше мануал тестировщиков/etc).
См. пункт выше. Вопрос бессмысленный без привязки к задачам, которые вы собираетесь решать.
И да и нет, зависит от сложности вашего приложения.
Работают как по отдельности, так и вместе, дело вкуса.
Не увидел какой-либо пользы в нем. Зачем писать вещи вроде
если можно сразу использовать полноценный BDD фреймворк вроде Cucumber/JBehave и писать нормальные тесты, вместо этих приседаний с псевдо-кодом в BDD стиле?
Не работал с JS фреймворками, но с JVM это решается организацией мультимодульного проекта с Maven/Gradle. Общий код выносится в один модуль, тесты для мобильных девайсов во второй, для фронтенда в третий и т.д.
P.S. универсальная рекомендация - поменьше пишите своих велосипедов, используйте уже готовые опенсорсные.
Стек\язык не принципиален. Нижесказанное в контексте selenium ui functional тестов
Время прогона всех тестов на всех конфигурациях === времени прогона самого долгого теста
Тесты запускаются на каждый PR (или чаще)
Встроены в pipeline и блокируют его при падениях
Отчеты\Репорты позволяют смотреть тренд и историю прогонов каждого теста. Содержат логи браузера, логи драйвера, скриншоты\видео, логи тестов, и вменяемые кастомные сообщения об ошибке, тестовые данные.
ИМХО: Фреймворк использует качественный OOP подход с разбиением на страницы, компоненты\фрагементы и свои кастомные элементы. Каждый объект тесно связан с кодом компонентом\фрагментом фронтед проекта. При изменении кода фрагмента на фронтенде - мы должны получить максимум апдейтов в своем объекте автоматически.
Поддержка максимального количества браузеров и платформ. Pairwise для запуска тестов на разных конфигурациях.
Основная масса тестов не использует реальный бекенд, а использует заглушки вместо. end-2-end тесты тоже есть - но как вишенка на торте.
Code coverage репорты для фронтенд кода автоматически после прогона. UI (client-side) performance отчеты автоматически после прогона. Потенциально - блокирование pipeline при неудовлетворительных результатах, которые анализируются автоматически.
Тестовая ферма (тестовый кластер с платформами\окружениями на которых бегут тесты) - расширяется динамически (autoscaling) и не простаивает без задач.
Фреймворк использует качественный OOP подход с разбиением на страницы, компоненты\фрагементы и свои кастомные элементы. Каждый объект тесно связан с кодом компонентом\фрагментом фронтед проекта. При изменении кода фрагмента на фронтенде - мы должны получить максимум апдейтов в своем объекте автоматически.
А ничем. Это не замена, а развитие - page components, html elements, fragments … - это все об одном и том же - инкапсуляция логики взаимодействия со страницей в обьекты\классы
Можно и так и так. Потребности не такие жесткие как у backend, но в то же время требуется бОльшая гибкость в запуске и остановке чтобы не тратить лишние деньги.
