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

GlaceJS - фреймворк для функционального тестирования на JavaScript

mocha
framework
page-object
reporting
javascript
Теги: #<Tag:0x00007fedbbbd6c20> #<Tag:0x00007fedbbbd6ae0> #<Tag:0x00007fedbbbd6810> #<Tag:0x00007fedbbbd66d0> #<Tag:0x00007fedbbbd6590>

(Sergei Chipiga) #1

Всем привет!

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

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

  • Кросс-платформенный
  • Использует mochajs как тест-раннер.
  • Имеет свою систему тестов и репортеров.
  • Ориентирован на сложные функциональные сценарии.
  • Поддерживает множественные независимые верикации внутри одного теста.
  • Поддерживает параметризацию внутри и снаружи теста.
  • Имеет встроенный опциональный механизм перезапуска упавших тестов и верификаций. Ключи запуска --retry <number> и -retry-chunk <number> соответственно.
  • Поддерживает из коробки систему множественных репортов с возможностью подключения своих.
  • Имеет встроенный репортер в консоль и TestRail. Поддержка Allure в ближайших планах. Ключ подключения --testrail.
  • Запускает внутри себя селениум-сервер, если не указаны настройки для подключения к внешнему. Ключ подключения веб-тестов --web.
  • Поддерживает Page Object Pattern.
  • Умеет сравнивать два изображения и говорить похожи или нет.
  • Умеет искать картинку в картинке и говорить есть или нет.
  • Может писать видео выполнения тестов. Пока не поддерживается на macOS, но скоро появится. Ключи запуска --video (удаляется, если тест пройдет) и --force-video (видео сохраняется в любом случае).
  • Умеет запускать Xvfb сервер, а также писать с него видео. Ключ запуска --xvfb или --xvfb 1280x720.
  • Включает 2 типа прокси: обычный http и transparent (chrome browser only). Ключи подключения --proxy и --global-proxy. Могут работать вместе или отдельно.
  • Поддерживает middleware для обоих прокси, можно подключать свои middleware.
  • Включает middleware для кеширования ответов с сервера. Ключ --cache или --existing-cache (использует уже сохраненные данные, если не были удалены). Пока только агрессивное кэширование, без соответствия http-протоколу, но скоро будет.
  • Включает middleware для управления скоростью ответов прокси.
  • Включает middleware для сбора информации об ответах сервера.
  • Поддерживает хранение CLI опций в JSON-конфиге.
  • Поддерживает расширение дефолного конфига собственным.
  • Включает примеры на все основные возможности c указанием команд запуска.

Чтобы установить проект:

  • Поставить java, chrome browser. Для unix-систем imagemagick, ffmpeg или avconv. Для windows-систем imagemagick и ffmpeg устанавливаются при установке glacejs.
  • Поставить nodejs>=7.6 и npm>=4.0, компилятор нативных модулей для nodejs.
  • Установить через npm: npm i glacejs
  • Или установить из исходников и попробовать рабочие примеры:
git clone https://github.com/schipiga/glacejs.git
cd glacejs
npm i

Сейчас проект на стадии активного расширения документации, возможностей и устранения мелких недочетов. Поэтому любой usage experience, contribution & issues приветствуются.

Cчитаете ли вы проект полезным?

  • да
  • нет

0 участников


(Mykhailo Poliarush) #2

@Sergei_Chipiga предлагаю написать пару статей с примерами и объяснениями на todo приложении, чтобы больше показать возможностей твоего решения

А за инициативу и новую разработку :thumbsup: добавляй ссылку на


(Sergei Chipiga) #3

@polusok, ok спасибо :slight_smile: Да тоже думаю об этом, на самом деле инфы по JS накопилось на несколько статей, так что в ближайшее время возьмусь.


(Michael Bodnarchuk) #4

Звучит прикольно, но пока вообще непонятно :slight_smile:
Сайт и описание дает структурированый набор фактов, но к сожалению мало use-case’ов. То есть хотелось бы понять:

  • в каких случаях и для чего следует использовать GladeJS
  • сравнение с альтернативными фреймворками
  • чем GladeJS лучше чем написать всё то же ручками

Мне кажется эти моменты важны для создания первичной документации. Чем-то же надо заманивать новых юзеров.

P,S, И последний вопрос. Не удержался. Почему в примерах так много SS? Почему SS? Третий рейх спонсирует? :wink:


(Sergei Chipiga) #5

@davert, спасибо за замечания. Да документация не такая как хотелось бы ее видеть. Сперва было интереснее делать проект, чем разрабатывать документацию. Но надеюсь по мере сил уделять ей время.

По поводу, когда стоит использовать GlaceJS, я думаю тогда, когда вам нужны описанные выше фичи, которые работают из коробки :slight_smile: Проект в первую очередь делался из личного интереса напрогать что-то свое, не ограничивая полет фантазии. Причем большая часть кода из этого проекта используется в моей текущей работе.

Сравнение с альтернативами. Фичи, которые есть, были добавлены, потому что возможности mochajs не удовлетворяли потребности по работе. Хотелось сделать проект, в котором то, что нужно, работает из коробки, и позволяет быстро стартовать разработку автотестов.
К примеру, при моем собеседовании на JS я бы не отказался от такого фреймворка, по сравнению с тем убожеством, которое я слепил на mochajs в качестве тестового задания. А плюс еще и заявить, что являешься автором этого фреймворка.
А делать детальное сравнение с тем что умеют/не умеют другие фреймворки и их плагины, я извиняюсь, но мне как-то жаль сливать на это свое время.

По поводу того, что ‘чем GlaсeJS лучше чем написать всё то же ручками’. Н-р я предпочел бы уже готовое решение, чем делать велосипед. Опять же в этот код вложено несколько месяцев разработки, и код работает на реальном проекте.

‘Почему в примерах так много SS? Почему SS? Третий рейх спонсирует?’ - Пока нет, но будет забавно услышать отказ использовать GlaceJS по идеологическим соображениям :slight_smile: SS - это неймспейс для степов. К сожалению $ и $$ используются webdriverio, не хотелось перекрывать.
А множественное использование, т.к. мне нравится юзать async/await. Можно было бы заморочиться с chainable вызовами, но это дополнительный код для степов, и в целом такой подход усложняет отладку, т.к. нужно вовлекать промисовый then где вызывать console.log или debugger, да и вообще чуть-что и сразу нужно вызывать then и юзать голый промис. В общем половинчатое решение. Надеюсь в ближайшее время написать статью про различные подходы фреймворков к асинхронным тестам на JS, заодно рассказать про подводные камни в mochajs.


(Sergei Chipiga) #6

@davert, кстати CodeceptJS прикольно выглядит. Глянул у вас статью про него. Интересно будет покопаться в нем изнутри.


(Michael Bodnarchuk) #7

кстати CodeceptJS прикольно выглядит. Глянул у вас статью про него. Интересно будет покопаться в нем изнутри.

Тоже Mocha, тоже webdriverio, но конечно плагинов и штук для расширения меньше чем у вас :slight_smile:

Скажу, что сторонние разработчики (и в особенности их компании) очень неохотно идут на внедрение standalone-фрйемворк"ов. Потому возможно вы могли бы сделать архитектуру более модульной, чтобы, допустим видео можно было писать с любыми webdriverio тестами. Например, прокси, xvfb, видео, кеширование, testrail и т.п. может быть доступно как модули, а ваш основной проект красиво их собирает. Кому не надо что-то из этого - не тянет.


(Sergei Chipiga) #8

@davert, да модульность - это и интересная задача, и выглядит гибко. В планах было вынести, как минимум рекордер и прокси в отдельные утилиты, Проблема пока упирается в недостаток свободного времени :slight_smile: Проще было сначала сделать standalone-фреймворк, а теперь неспеша можно его разносить на части.


(Sergei Chipiga) #9

@davert, кстати по CodeceptJS, в readme сказано: “You don’t need to worry about asynchronous nature of NodeJS or about various APIs of Selenium, PhantomJS, Protractor, etc, as CodeceptJS unifies them and makes them work as they were synchronous.”

То есть если мне нужно вызвать в тесте какую-либо асинхронную функцию из сторонней библиотеки, то CodeceptJS ее распознает и выполнит как синхронную? Или есть простой механизм регистрации асинхронных функций, вроде Codecept.registerAsSync(myAsyncFunc), после чего можно ее юзать как синхронную?


(Sergei Chipiga) #10

@davert и еще вопрос по CodeceptJS. Если я между вызовами методов объекта I поставлю console.log(someMyObject), то console.log произойдет синхронно, н-р после запуска браузера?


(Michael Bodnarchuk) #12

Да, такой механизм есть. Все промисы добавляются в глобальную цепочку. Codecept.registerAsSync как бы существует, но он из категории Advanced API. По умолчанию предлагается писать свои хэлперы. Если функция в хэлпере возвращает промис - она будет синхронизирована со всем стеком.

Если не забыть поставить yield перед ним, то да :slight_smile:
Работает принцип async/await только его чуть более ранняя версия. Любой тест может быть генератором, а yield прерывает его выполнение. Таким образом, можно, например, получать данные из теста, делать console.log и продолжать выполнение. Идея в том, чтобы не привращать тест в постоянное yield, yield, yield на каждой строчке и избежать повторений там где это не нужно


(Sergei Chipiga) #13

@davert, я согласен, что это в целом хорошо избавить от постоянного указания yield или await. Но честно говоря меня это смущает скорее по идеологическим причинам. Даже если не брать в расчет, что для того чтобы обеспечить псевдо-синхронный код, в недрах CodeceptJS реализована наверняка сложная логика с добавлением в очередь, эмитированием событий и т.п.
Меня более смущает тот факт, что от пользователя скрывают истинную суть JavaScript, что он асинхронный, создавая иллюзию синхронности. Что конечно снижает порог вхождения, но и снижает уровень знаний. На мой взгляд инженер должен понимать природу языка на котором он пишет.


(Michael Bodnarchuk) #14

Ну тут есть несколько моментов. 1. async/await тоже по своему скрывает настоящую суть JavaScript - эта конструкция всего лишь обертка над промисами. 2. вот конкретно в сфере автоматизированого тестирования асинхронность только мешает. Любой маломалькский вызов асинхронен и честно говоря, каких-то плюсов эта асинхронность не дает.

Если посмотрите, то Protractor/SeleniumWebDriverJS тоже прячут асинхронность в глобальных промисах.
А webdriverio предлагает использовать файберы для синхронизации шагов.

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


(Sergei Chipiga) #15

@davert, покопаюсь в CodeceptJS, тогда наверное отвечу по существу :slight_smile: Сейчас не хочется водить вилами по воде.