×

UI-автоматизация, или Почему стоит посмотреть в сторону JavaScript

Всем привет! Посещая конференции или просто общаясь с коллегами, я часто сталкиваюсь с тем, что для UI-автоматизации по умолчанию выбирают Java, в более редких случаях — Python или C#. При этом часто те, кто делает такой выбор, просто не знают, что можно предпочесть иной вариант. В этой статье я хочу поделиться своими наблюдениями и личным опытом: каково это, построить эффективную автоматизацию на JavaScript, — а также рассмотреть варианты различных фреймворков, которые существуют на рынке.

Аргументы в пользу JavaScript

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

Разница между языками все больше стирается и становится незаметней. Поэтому, просматривая современные тренды в автоматизации, можно заметить, что все больше проектов используют JavaScript для разных уровней и видов тестирования. Как пример можно привести статистику Github за 2018 год по популярности языков программирования.

В нашем проекте мы столкнулись с выбором нового фреймворка и используемых технологий. В итоге мы пришли к решению взять JavaScript и WebdriverIO-фреймворк для UI-автоматизации. Рассмотрим подробнее, почему так решили и что вышло в итоге.

Первое, на что нужно обратить внимание при выборе языка для автоматизации, это стек технологий, которые используются в проекте. В нашем случае в проекте применялись Python, PHP, React (JS), что в свое время обусловило выбор фреймворка для автоматизации на PHP.

Но со временем тесты было все сложнее поддерживать из-за непродуманной архитектуры и и отсутствия обновлений для фреймворка на протяжении долгого времени. Появлялись сложности перехода на Selenium 3 из-за кастомных доработок используемой в проекте библиотеки. Также со временем стало понятно, что порог входа в проект по автоматизации стал очень высоким, обучать Manual QA писать тесты было сложно.

Всей командой мы решили попробовать перейти на новые технологии. Основными факторами перехода именно на JavaScript стали: скорость написания, настраивания; наличие знаний и опыта в команде и более быстрый вход в проект для QA, которые только начинают изучать автоматизацию.

Для того чтобы начать автоматизировать на JS, стоит изучить базовые основы языка, узнать, как работает Selenium, и выбрать один из фреймворков, что иногда бывает сложновато в связи с огромным количеством различных вариантов.

Рассмотрим подробнее фреймворки, библиотеки-обертки над Selenium, популярные сейчас.

Обзор JS-фреймворков для end-to-end-тестирования

Статистика загрузок основных библиотек сегодня выглядит так:

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

Например, Protractor хорошо подходит для проектов, написанных на Angular, потому что в нем есть встроенные функции для специфических загрузок Angular-элементов.

Ниже статистика количества звезд и открытых issues в библиотеках. Здесь явно можно выделить WebdriverIO, который стабильно имеет хороший показатель закрытых проблем.

Protractor

Плюсы:

  • Protractor — это единственный фреймворк, который из коробки поддерживает кастомные определения AngularJS-элементов. Если у вас Angular, используйте Protractor.
  • Удобная поддержка TypeScript и разных фреймворков для unit testing (Jasmine, Mocha, Cucumber и пр.).

Минусы:

  • Нет поддержки мобильного тестирования.
  • Написан как обертка над WebDriverJS. Если будут проблемы с WebDriverJS, автоматически они будут и в ProtractorJS.

Базовый пример теста на ProtractorJS:

Nightwatch.js

Плюсы:

  • Похож на WebdriverIO и тоже является кастомной имплементацией W3C WebDriver API.
  • Легко добавить новую функцию.
  • Не нужно выбирать между Jasmine и Mocha.

Минусы:

  • Нет поддержки Mocha и мобильного тестирования.
  • Меньше поддержки, чем у WebdriverIO и Protractor.

Cypress

Плюсы:

  • В отличие от большинства end-to-end-фреймворков, не использует Selenium. Архитектура работы с браузером была написана полностью, и, в отличие от Selenium, Cypress не запускает удаленные команды через сеть, а работает напрямую с программой.
  • Быстрая и удобная настройка. Необходимо запустить только одну команду для установки всех пакетов, и нет необходимости ставить все отдельно.

  • Вся документация в одном месте, не нужно отдельно искать, как правильно делать проверки или как использовать Chai.
  • Необычный интерфейс запуска с описанием, какие команды выполняются, что позволяет быстрее понимать, что происходит на странице в определенный момент.

Минусы:

  • Плюс, который в то же время является и минусом, — это тот факт, что Cypress не использует Selenium для end-to-end-тестирования. Что порождает много проблем в работе. Работа с браузером не всегда стабильна, и на сегодняшний день на GitHub висят открытыми более чем 900 проблем.
  • Нет поддержки мобильного тестирования, и, судя по комментариям создателей нативной поддержки, никогда и не будет.
  • Поддержка ограниченного количества браузеров: Canary, Chrome, Chromium, Electron.
  • Платная параллелизация тестов. Хотите запускать в несколько потоков — придется платить.

WebdriverIO

Плюсы:

  • WebdriverIO — это кастомная имплементация W3C WebDriver API. Не нужно привязываться к имплементации WebDriverJS.
  • Поддержка синхронного кода. Можно забыть об асинхронности JavaScript.
  • Удобная базовая настройка с помощью встроенного интерфейса для командной строки wdio.
  • Поддерживает почти все тестовые фреймворки BDD и TDD.
  • Поддерживает удобную библиотеку ‘webdrivercss’ для сравнения CSS-стилей элементов на странице.

Минусы:

  • Большое различие между последними версиями (WebdriverIO 4 и 5).
  • Хуже кастомизирован для автоматизации AngularJS, чем Protractor.

Пример теста Login. Основное, на что можно обратить внимание, это отсутствие await/async или Promises. В этом примере был использован паттерн Page Object, фикстуры и другие подходы, которые применяются при написании автоматизации.

Синхронность WebdriverIO обеспечивает технология Fibers, иногда ее еще называют coroutines. У этой технологии много плюсов и преимуществ, но существуют подводные камни, например запуск в асинхронном коде сделает весь код асинхронным. Как по мне, за этой технологией будущее.

Приступить к написанию первых тестов с помощью этой библиотеки очень просто. Для начала нужно установить npm-пакет @wdio/cli в новосозданном проекте.

npm i --save-dev @wdio/cli

После этого необходимо сгенерировать конфиг для запуска тестов с помощью команды WebdriverIO.

./node_modules/.bin/wdio config

Я предпочитаю Mocha как тестовый фреймворк и sync-режим для запуска тестов. Из репортеров на начальном этапе можно использовать Spec-репортер, который красиво выведет результаты тестов в консоль, при дальнейшем росте проекта несколькими строчками можно будет добавить Allure. В дополнение к этому при изначальной настройке проекта можно добавить wdio-selenium-standalone-service, который будет менеджить запуск Selenium WebDriver, без необходимости отдельно ставить СhromeDriver.

Теперь все готово к запуску первого теста. Нужно создать тестовый файл, в котором будем описывать тесты. Пример базового теста может выглядеть как-то так:

describe('dou.ua page', () => {
 it('should have the right title', () => {
 browser.url('https://dou.ua');
 const title = browser.getTitle();
 assert.strictEqual(title, 'Сообщество программистов | DOU');
 });
});

Где командой browser.url('') мы открываем браузер и можем сразу делать все необходимые проверки.

Автоматизация — это несложно. Как говорится, главное начать.

Полезные материалы

Выводы

В заключение перечислим преимущества и недостатки использования JavaScript-фреймворков для автоматизации тестирования, которые мы заметили в нашем проекте.

Преимущества:

  • Скорость написания тестов значительно выше, чем на Java или C#.
  • Ниже порог входа для старта проекта.
  • Больше взаимодействия внутри команды (проявилось в нашей команде, что, может, и не относится к выбору фреймворка автоматизации).
  • Большое количество готовых решений очень разных проблем, которые возникают.

Недостатки:

  • Менее стабильные решения. Иногда может выйти так, что убил полдня на баг во фреймворке.
  • Для написания хороших тестов нужно понимание, как работает JavaScript.

У каждого решения/языка/технологии есть свои достоинства и свои недостатки. С выбором технологического стека определяться вам. Этот выбор зависит от состава вашей команды, от знаний и опыта ее участников, а также от задач, которые вы хотите решить. Если условия позволяют, обязательно пробуйте новое и смотрите в сторону развивающихся технологий. Только в таком случае удастся найти то, что подойдет именно вам.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному3
LinkedIn

Схожі статті




42 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Год назад был детальный разбор по теме: seleniumcamp.com/...​ess-vs-selenium-wrappers
;)

Допоможіть з завданням, наперед дякую) Write an automation script using Selenium WebDriver and Maven with Java or C# as language which will open google start page and make a search request with random word.

Kotlin+Selenide для UI тестирования вообще огонь

Я бы так радостно не рекомендовал протрактор направо и налево. Проект очень вяло развивается, пулл-реквесты висят месяцами, баги практически не фиксятся.Медленное увядание... увы.

Для новых проектов я бы рекомендовала Webdriverio или Cypress

Про протрактор вы написали полный бред. Он не для Ангуляра. Сайпрес лучше подойдёт для тестов ниже UI уровня... На чем вы пишите?

Ух... щас бы брать асинхронные языки, потом синхронить их и писать как на джавке\пайтоне.

UI тестирование синхронное по своей природе, так что выбор небольшой.

Основна проблема будь якого переходу з мови Х на мову Y — основна маса людей чомусь починає займатись натягуванням сови на глобус в стилі «раніше було краще».
Результат: «Я, чувак з 9000 років автоматизації на мові А, приходжу пилити фреймворк на js, записую проміс в змінну, викликаю, а мені в консоль падає якась дічь — ну і фігня цей ваш js, де тут типи, компілятор і оті всі плюшки які були в моїй зоні комфорту? Ну його в баню, давайте далі писати на А, там все простіше».

По хорошому, потрібно відокремлювати інструменти (webdriverjs, puppeteer) і фреймворки. Так як на базі інструментів потрібно пилити велику купу бойлерплейту, але «свою та рідну» — і у разі невдачі, здебільшого це недолік власної архітектури, а не проблема js. Фреймворки, в свою чергу, накладають свої обмеження і trade-offs. На додачу, деякі є обгортками навколо селеніум (wdio, protractor), а деякі є окремими тулами з своїм стайл гайдом, особливостями і концепціями (cypress).

Якщо ж починати перехід з розумінням того, що в js «не все як у людей» і бути готовим до змін — з часом написання і підтримка тестів швидша і простіша за інші мови (особисто порівнював з с#). Якщо ж, наприклад, зрозуміти що хоче Cypress від твого коду — то процес стає ще швидшим ніж на інших js рішеннях. На проекті ганяємо Cypress + cucumber + allure, для тестів логіну окремий скрипт на puppeteer, в тестах авторизація через апі — політ нормальний.

Рекомендую хороший виступ Михайла Боднарчука (автора codeceptjs — фреймворк над селеніум обгортками) про муки вибору інструментарія:
youtu.be/0m7rNBBkezU

P.S. Щодо платних фішок сайпреса — можна спокійно юзати і без їх сервісів, використовуючи як тест раннер з своїм репортером і стратегіями паралелізації. По факту вони просто дають можливість записувати результати паралельних запусків в свій дешборд. Велика частина ішью на гітхабі — купа проблем із застарілою версією їх дефолт браузера Електрон. Якщо запускати в Хромі — все ок.

WDIO это не обёртка над селениумом, а собственная имплементация jsonwp и w3c протоколов

Так радуюсь за людей, которые в своём маня-мирке истинно считают, что кроме веба в мире ничего не существует

Никто и не говорит, что в мире ничего кроме веба не существует.
Статья не покрывает все виды автоматизации, а конкретно рассказывает про технологии которые можно использовать в UI тестировании веб интерфейсов.

Дякую! Стаття дуже вчасна. Викладаю на курсах QA Auto і моніторю вакансії, то пропрозицій в автоматизації на JS стає все більше, особливо в стартапах і віддалених варіантах роботи.

Как пример можно привести статистику Github за 2018 год по популярности языков программирования.

Количество != качество. И JS это язык на котором писать что-то работающее как тебе надо очень сложно, таблица операций между типами наркоманская, вместо классов что попало, а пачки функций и данных мало кто тягает. Ну и компайлтайм типов нет, и по этому компиялтор баги за юзера вычищать не будет. По этому, о чём то надёжном на JS можно забыть.

И JS это язык на котором писать что-то работающее как тебе надо очень сложно

Разработчики как-то умудряются.

таблица операций между типами наркоманская,

Дело вкуса, как и в любом другом динамическом языке программирования.

вместо классов что попало,

Вот тут непонятно. В JS есть вполне себе выделенная сущность class.

а пачки функций и данных мало кто тягает.

Не ООП единым. Собственно, ничто не мешает все операции выразить в виде функций. Такая себе функциональная декомпозиция.

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

Это типичное ограничение языков с динамической типизацией. В принципе, это не помешало в свое время стать популярными для автотестов такие языки как Ruby, Python. Но если все-таки данная проблема создает слишком много неприятностей, то всегда можно перенести проект на Typescript. Там проблем с типами заметно меньше. Да и значительная часть проектов, с которыми приходилось сталкиваться, уже вовсю используют Typescript вместо Javascript.

По этому, о чём то надёжном на JS можно забыть.

На самом деле, это вопрос прямых рук, не более того.

Спасибо за интересную статью, Вставлю свои 5 копеек: если вдруг у вас во фронтенде используется Ext JS Лучше не изобретать велосипед со всякими «самохилящимися» сервисами а использовать тест фреймворк «от производителя» Sencha Test

все больше проектов используют JavaScript для разных уровней и видов тестирования. Как пример можно привести статистику Github за 2018 год по популярности языков программирования.

Яке відношення це має один до одного? Це ж статистика мов програмування, а не мов програмування для автомейшну.
Імхо, зв’язка Selenium+Java на першому місці по частоті використання.

Скорость написания тестов значительно выше, чем на Java или C#.

Не знаю, як там C#, але для Java є Selenium-обгортка — Selenide. Я так оком глянув, то там все дуже легко і просто, ну на реальних проектах хз як там.
Тому по швидкості не все так очевидно :)

А загалом, дякую за статтю!

На реальних проектах все теж дуже легко — перевiрено на менi, а також чехах, словаках i навiть iндусах.

Я бы ещё упомянул Puppeteer от Google, имел недавний опыт, с одной стороны позволяет полностью получить контроль над происходящим в браузере включая дев-консоль, с другой дебаг на JS-кода — это боль, в итоге по скорости написания и поддержке E2E тестов Selenium+Java/Python всё равно побеждает

Я тоже использую JS для автоматизации, но мне кажется что многие аргументы из этой статьи ошибочны:

1. Низкий порог входа, это не о JS (с его асинхронным подходом к написанию кода и большой сложности дебага асинхронного кода Вам будет легко писать только самые простые ЮИ тесты. Сложные функциональные тесты с отложенными АПИ запросами, запросами в БД для подготовительных шагов и дебаг всего этого асинхронного поведения и Вы очень быстро понимаете почему люди с малым опытом разработки используют Java, C#, PHP и т.п.)
2. Писать лапша код для «типа» тестов которые потом очень сложно сапортить — тоже легко. Но собирать адекватный проект со стандартными правилами наследования, переиспользованием кода через наследование и композицию на JS с его обьектно-прототипной моделью будет уже не так просто. (Именно поэтому я советую начинающим AQA начинать с JAVA или С# чтобы они имели крепкий фундамент и понимание ООП, с JS это будет намного сложнее)

Я использую JS совершенно по другим причинам:
1. Асинхронная природа JS позволяет мне запускать большие объемы отдельных АПИ тестов в параллель без форка процессов (на значительно более слабой машине чем теже тесты на РНР с форком процессов), а когда все тесты идут параллельно это очень экономит время прогона тестовых комплектов (2000 сложных функциональнных АПИ тестов за 7мин на JS, а это более 50000 тысяч отдельных апи запросов с валидацией ответов)
2. Огромный opensource репозиторий npm node.js — здесь можно найти модули для любых задач
3. Работать с JSON в JS одно удовольствие ;)
4. В целом сейчас JS хайп, язык развивается очень быстро и насыщается многими отличнейшими конструкциями и подходами (так что свое место на рынке автоматизации он займет прочно, особенно в тех конторах где бек и фронт написан на JS)

для UI-автоматизации по умолчанию выбирают Java

И это очень хорошо :)
Вместо того чтобы испытывать боль с прелестями JS(привет async, await) посмотрите лучше на Selenide.
P.S. писал тесты на WebdriverIO, Proctractor, а так же на сишарпе и пайтоне.

Дякую за статтю, на рахунок порогу входу для таких мов як Java/C#/Python, то зараз є купа врапперів і фреймворків, які безболісно дають можливість написати звичайний тест теж за 5 хв. Звісно, не все так однозначно, але)

Дякую за статтю. А критики тут і так накидають :)

Скорость написания тестов значительно выше, чем на Java или C#.

Каким образом замеряли?

Ниже порог входа для старта проекта.

Ниже порог входа чем что? Почему?

Для написания хороших тестов нужно понимание, как работает JavaScript.

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

Люблю одни и те же статьи/доклады/презентации, где каждый доказывает преимущества своего языка/инструмента/фреймворка с одинаковыми выводами 😏

1. Замеряли при выборе технологии, которую будем использовать, взяли один и тот же кейс и написали на Java и JS тест, в нашем случае было быстрее писать проверки с использованием JavaScript.
Согласна с вами — это действительно довольно субъективный показатель.
2. Ниже порог входа для Manual QA, Java/С# очень хорошие языки, но есть проекты для которых они излишне сложные. Если вам просто нужно проверить что страница загрузилась и кликнуть на кнопку, не вижу смысла заморачиваться со сложными фреймворками.
3. Так и есть, для написание чего угодно, стоит понимать как работает язык программирования. Но часто люди думаю что знание методов Selenium достаточно.

«Основными факторами перехода именно на JavaScript стали: скорость написания»
Оце найбільше викликиє сумніви. Швидкість просто каписати тест і швидкість всього його життєвого циклу: створення, дебаг, рефакторинг, розширення, тощо це різні речі, і для новачків і для досвідчених розробників. Для новачків мабуть це ще більший час. Сам теж думаю попробувати UI автоматизацію на JS, але писати буду на type script.
Є досвід переходу команди сеніор розробників з Java backend на Full stack розробників з JS для фронта в одній компанії (Farata systems), то швидкість виконання задач на фронтенді впала в рази порівняно з бекендом. В результаті було обрано перехід саме на type script.

Для написания хороших тестов нужно понимание, как работает JavaScript.

Гениальная фраза. А для написания тестов на Java/C#/Python можно наплевать на то как они работают?)
Впрочем, утрирую. Очевидно, что следует понимать как работает язык и фреймворк для того, чтобы писать тесты.

Это скорее фраза напутствие, что стоит учить не только как работает Selenium, но и основные принципы и основы языка с которым работаешь.

С другими фреймворками не работал, но Protractor — это иногда просто адище.

await та async — це стоп слова для автоматизації :)
На мою думку, зараз слід підходити до автоматизації перевірок не зі сторони «А яку мову обрати», а зі сторони «А що треба автоматизувати» та як би то банально не звучало — «Що використовують розробники»
Ібо чим ближче по розумінню автоматизовані перевірки до розробника — тим більше вони ціності приносять

Дякую за оглядову статтю)

await та async — це стоп слова для автоматизації :)

Чего так?

Ну це ІМХО
Оскільки нажаль в автоматизації перевірок за допомогою жс, слід досить часто вказувати авейт, ібо ЖС асінхроний — а перевірки мають бути «синхроними» (мають мати чітку послідовність кроків)

Вдио на жс есть синхронный вариант. Но асинхронность, хоть и мало где надо в автоматизации, тоже оружие годное. Есть и свои минусы конечно, но чтоб прямо стоп слова)

Как раз исходя с принципа «ближе к разработке» я считаю, что для UI автоматизации стоит переходить на фреймворки написанные на тех же языках что и UI приложения.
Это так же дает возможность писать тесты в том же репозитории, где лежит основной код.

Пожалуйста, постаралась максимально рассмотреть существующие варианты)

я считаю, что для UI автоматизации стоит переходить на фреймворки написанные на тех же языках что и UI приложения

Эээ... А зачем, собссно? Это ИМХО имеет смысл только в 1 случае: у нас с разрабами общая репа и все тесты (а не только unit) падают в папку test в репе проекта. Но ИМХО смысла в данном подходе немного: плюсов, кроме наличия 1 репы, я не нахожу (CI всё равно, какую репу клонировать для запуска тестов), а минус — жёсткая привязка в технологиям, используемым в разработке: к примеру, если надо обновить версию либы, то сделать это будет непросто, потому что может затронуть код проекта.

Плюс в тому, що можна обрати лише одну точку в репозиторії перед релізом, коли, і нові фічі вже є, і всі тести для них зробили зеленими і навісити на цю точку тег реліза.
А так треба десь в вікі вручну синзронізувати 2 точки в різних репозиторіях.

Ну я поки не спробував не міг так вільно і з чістою совістю то казати :)
В мене насправді так і є: одна репа для додатка та тестів компонентних + для оточень, я повністю включений в код рев’ю активінсть і відповідно я не просто переглядаю їх тести, а ще їх і редагую, або підказую розробникам які тести дописати до якогось функціонала. І відповідно розробники мені то підказують
Вони переглядають мій код: використовують написані мною тести для локальних перевірок того що вони написали ну і як раз зараз коли зарелізимось — ми перейдемо до того що розробники будуть фіксити тести для оточення самостійно.
Всі тести я контролюю в репозиторії — щось переношу на інтеграційний рівень, а щось на юніт
Розробники від того дуже раді на проекті і як показник в нас більше 100 інтеграційних тестів, біля 300 юнітів, 37 тестів на оточення та 1 UI
Звісно все залежить від проекту — але до цього я дійшов немалими власними зусиллями

Також бонус від такого підходу — в тому що я дуже добре розбираюсь в проекті та гнучко для себе можу виконувати дослідницьке тестування із всеможливими моками для нашої алікаціїї, а це і затримки відповіді, це і просто захардкоджені значення, помилки від інтеграцій, тощо..

Якщо ви скажете, а хто ж буде підтримувати ті тести що написані — розробники будуть підтримувати їх і буде достатньо значно меншої кількості тест інженерів щоб перевірити аплікацію

Я вважаю що автоматизацтори як окремі особистості — це waste якщо їх рішення не використувують розробники (звісно в контексті проекту все слід сприймати).
І вважаю що більшість автоматизаторів слід звільнити якщо вони не можуть зробити зрозуміле рішення для розробника. А ручні тестувальники будуть дійсно вічні
А деякі матьорі автоматизатори (вже як SDET краще рахувати) — вони можуть взяти на себе роль котролю якості кодвої бази та проекту в загалом — і бути підтримкою для функціональних розробників, як наразі існують DevOps (з одної сторони брєд як роль, але не брєд коли копнути в цьому напрямку та зрозуміти наскільки там багато нюансів)

Не прагматично робити висновки про щось, поки на практиці не спроуєш то :)

Супер :)
Просто в статті є тільки одна непряма згадка про це)
Тому зауважив цей підхід до вибору
Ну і хочу ще наступне зауважити: що відповідний підхід зручно використовувати ще й для бекенд тестування :)

Підписатись на коментарі