Онлайн сервис проверки работы кода перед добавлением на сайт
Доброго времени суток 🙂
Сегодня хочу рассказать Вам, как можно проверять любой JavaScript, HTML, CSS на работоспособность перед тем как устанавливать его себе на сайт. Под проверкой, я подразумеваю не синтаксис, а предосмотр. То есть посмотреть каков будет конечный результат. Часто на сайт нужно добавить какую-нибудь форму, блок или элемент использующий CSS анимацию или JavaScript, jQuery. Правильно подключать весь код к себе на сайт не всегда удобно и быстро, поэтому можно воспользоваться онлайн-сервисом, который покажет Вам конечный результат.
Для начала перейдите на сайт jsfiddle.net там Вы увидите перед собой страницу, разбитую на разные зоны. Для начала нужо обратить внимание на самые большие, которые предназначены для добавления кода.
Как видите есть 4 окошка:
У каждого окошка есть настройки, возле названия есть иконка маленькой звездочки, при нажатии на которую, появляется окошко с настройками. На примере окна для JavaScript появится вот такое:
Если Вы уже какое-то время занимаетесь версткой, то могли уже не раз встречать примеры скриптов размещенных на этом сервисе. Рекомендую добавить данный сервис в свой набор инструментов для верстки. Рано или поздно он Вам пригодится, а если моя статья помогла познакомится с этим инструментом, буду очень рад.
На этом все, спасибо за внимание. 🙂
Если Вам был полезным мой труд, можете финансово поддержать сайт или отключить блокировщик рекламы, что займет 2 минуты 🙂
[в закладки] Инструменты для тестирования JavaScript-проектов
Автор материала, перевод которого мы публикуем сегодня, сотрудник Welldone Software, говорит, что если в двух словах рассказать об инструментах для тестирования JavaScript-проектов, то для модульного и интеграционного тестирования рекомендуется использовать Jest, а для тестов пользовательского интерфейса — TestCafe. Однако каждый конкретный проект может нуждаться в чём-то особенном. Лучший способ найти именно то, что нужно — взять несколько инструментов, которые, как кажется, подойдут, и испытать их в действии. Эксперименты подскажут — на чём именно стоит остановиться.
Представляем вашему вниманию обзор наиболее широко используемых инструментов тестирования для JS-проектов, на которые стоит обратить внимание в 2018-м году.
Инструменты тестирования общего назначения
▍Jsdom
Jsdom — это JavaScript-реализация WHATWG DOM и стандартов HTML. Другими словами, jsdom имитирует окружение браузера, не выполняя ничего кроме обычного JS.
В подобном окружении тесты могут выполняться очень быстро. Минус jsdom заключается в том, что не всё можно симулировать за пределами реального браузера (например, при таком подходе не получится делать скриншоты), поэтому использование данного средства ограничивает возможности тестирования.
Стоит упомянуть, что сообщество JS интенсивно работает над jsdom и совершенствует этот инструмент. Возможности его текущей версии очень близки к настоящему браузеру.
▍Istanbul
Инструмент Istanbul позволяет анализировать покрытие кода модульными тестами. Он выводит детальные отчёты, ориентируясь на которые можно получить точное представление о том, что в проекте ещё не протестировано, и оценить объём работ, необходимый для улучшения ситуации.
▍Karma
Karma позволяет запускать тесты в браузере и в средах, напоминающих браузеры, в том числе — в jsdom.
Karma поддерживает сервер тестирования со специальной веб-страницей, в окружении которой и будут выполняться тесты. Эту страницу можно открывать во множестве браузеров. Кроме того, это означает возможность удалённого проведения тестов с использованием сервисов вроде BrowserStack.
Chai — это самая популярная библиотека для создания утверждений.
▍Unexpected
Unexpected — это библиотека для создания утверждений, синтаксис которой немного отличается от Chai. Кроме того, эта библиотека расширяема, что позволяет создавать более продвинутые утверждения. В частности, речь идёт об использовании библиотек, основанных на unexpected, например таких, как unexpected-react, подробности о которой можно почитать здесь.
▍Sinon.JS
Sinon.JS представляет собой мощную автономную систему, предоставляющую возможность выполнять тестирование JavaScript-проектов с использованием так называемых шпионов (spy), заглушек (stub) и имитаций (mock). Эта система умеет работать с любыми фреймворками для модульного тестирования.
▍Testdouble.js
Testdouble.js — это менее популярная библиотека, выполняющая те же функции, что и Sinon, при этом её разработчики говорят о том, что она решает похожие задачи лучше, чем Sinon. Она отличается набором возможностей, некоторыми особенностями архитектуры и подходом к тестированию, что может сделать её полезной во многих ситуациях. Подробности о testdouble можно почитать здесь, здесь и здесь.
▍Wallaby
Wallaby — это ещё один инструмент, достойный упоминания. Он не бесплатен, но многие пользователи полагают, что он стоит тех денег, что за него просят. Wallaby работает в IDE (поддерживаются все основные IDE) и выполняет тесты, соответствующие изменениям кода. Данные о результатах тестирования выводятся в реальном времени там же, где находится код.
Wallaby
▍Cucumber
Cucumber помогает разработчикам с написанием тестов в BDD. Тесты разделены между файлами критериев приемлемости, подготовленных с использованием синтаксиса Gherkin, и собственно файлами тестов, которые им соответствуют. Тесты могут быть написаны на различных языках, которые поддерживает фреймворк, в том числе и на JS.
Вот пример файла like-article.feature :
Вот пример файла like-article.steps.js :
Многие команды находят этот синтаксис более удобным, чем TDD.
Фреймворки для модульного и интеграционного тестирования
Первое, что, вероятно, стоит выбрать при поиске подходящих инструментов тестирования — это фреймворк и библиотеки для его поддержки. Рекомендовано использовать то, что предоставляет выбранный фреймворк до тех пор, пока не возникнет необходимости в уникальных инструментах. Вот несколько общих рекомендаций:
▍Mocha
Mocha в настоящий момент является самой широко используемой библиотекой. В отличие от библиотеки Jasmine, о который мы ещё поговорим, эта библиотека применяет сторонние инструменты для построения утверждений и внешние средства для создания имитаций и функций-шпионов (обычно Enzyme и Chai). Это означает некоторые дополнительные сложности при настройке Mocha, и то, что получаемый функционал будет разделён между различными библиотеками, но этот фреймворк более гибок и расширяем в сравнении с Jasmine.
Например, если вам нужна особая логика утверждений, вы можете сделать форк Chai и заменить только Chai в своём наборе инструментов вашей собственной библиотекой для создания утверждений. Это можно сделать и в Jasmine, но в Mocha это изменение будет более очевидным.
Вот некоторые особенности Mocha, на которые стоит обратить внимание:
Jest — это фреймворк для тестирования, разработанный Facebook. Он основан на Jasmine. По состоянию на сегодняшний день компания Facebook переработала большую часть его функционала и создала на его основе множество новых возможностей.
Стоит отметить, что после анализа огромного количества материалов о Jest, мы можем сделать вывод о том, что многие разработчики впечатлены скоростью и удобством этого фреймворка. Среди особенностей Jest можно отметить следующие:
▍Jasmine
Jasmine — это фреймворк для тестирования, на котором основан Jest. Если есть Jest — кому может понадобиться Jasmine? Всё дело в том, что Jasmine появился раньше, чем Jest, по нему имеется огромное количество публикаций, для него создано множество инструментов.
Кроме того, создатели Angular всё ещё советуют использовать именно Jasmine, а не Jest, хотя и Jest отлично подходит для выполнения тестирования Angular-проектов, и многие пользуются им для этого. Вот основные особенности Jasmine:
Ava — это минималистичная библиотека для тестирования, поддерживающая параллельное выполнение тестов. Вот её основные характеристики:
Tape — это самый простой из рассматриваемых здесь фреймворков для тестирования, имеющий небольшое и понятное API. Это — обычный JS-файл, который работает в Node.js. Вот основные характеристики tape:
Средства тестирования пользовательского интерфейса
Для начала отметим, что здесь и здесь вы можете найти отличные материалы о сервис-провайдерах, мощности которых можно использовать для выполнения кросс-платформенного и кросс-браузерного тестирования.
Существующие инструменты для тестирования пользовательских интерфейсов очень сильно отличаются друг от друга, поэтому, прежде чем выбрать то, чем вы будете тестировать ваши интерфейсы, советуем поэкспериментировать. Если в двух словах выразить общие рекомендации, предназначенные для тех, кто выбирает среду для тестирования пользовательских интерфейсов, то можно сказать следующее:
▍Selenium
Selenium позволяет автоматизировать взаимодействие с браузером, имитируя действия пользователя. Этот фреймворк не создан специально для тестов, он может управлять браузером в различных целях, предоставляя сервер, который симулирует поведение пользователя в браузере с использованием программных механизмов.
Возможностями Selenium можно управлять различными способами, используя множество языков программирования, а применение некоторых инструментов позволяет работать с Selenium и вовсе без программирования.
Нам, однако, интересна конфигурация, в которой сервер Selenium управляется с помощью Selenium WebDriver, который служит слоем взаимодействия между Node.js и сервером, который управляет браузером. Схему взаимодействия различных частей системы можно описать так:
WebDriver можно импортировать в выбранный фреймворк для тестирования. Тесты можно писать с использованием возможностей по управлению браузером:
Кстати, и самого WebDriver может быть вполне достаточно для выполнения тестов. Встречаются рекомендации, авторы которых советуют использовать WebDriver в его исходном виде.
Однако, тут нельзя не учитывать то, что существуют библиотеки, расширяющие возможности WebDriver, представленные либо его форками, либо обёртками для него.
Минусы библиотек-обёрток заключаются в том, что они усложняют систему. В появлении форков плохо то, что усилия, затраченные на них, вполне могли бы быть вложены в разработку самого WebDriver.
Однако, если говорить о Selenium, многие предпочитают не использовать его напрямую. Взглянем на некоторые библиотеки, использующие возможности Selenium.
Appium
Appium предоставляет API, похожее на API Selenium. Этот фреймворк предназначен для организации тестирования мобильных проектов с использованием следующих инструментов:
Protractor
Protractor — это библиотека-обёртка для Selenium, которая ориентирована на Angular. Вот основные особенности этой библиотеки:
WebdriverIO
WebdriverIO предлагает собственный подход к использованию функционала Selenium WebDriver. Эта библиотека предназначена для Node.js. Среди особенностей этого проекта можно выделить следующие:
Nightwatch
Nightwatch также отличается собственным подходом к работе с Selenium WebDriver. Этот инструмент предоставляет собственный фреймворк для тестирования, в котором есть сервер, средства формирования утверждений, различные вспомогательные инструменты. Вот основные особенности Nightwatch:
▍TestCafe
TestCafe является отличной альтернативой инструментам, основанным на Selenium. Код этой библиотеки был открыт в конце 2016-го года. Надо отметить, что всё ещё существует платная версия TestCafe, которая предлагает средства для тестирования, не требующие программирования. Например — это инструменты для записи тестов. В рамках платной версии предлагается и поддержка пользователей. Надо отметить, что существует множество устаревших публикаций, которые вышли до открытия кода библиотеки и считают закрытый код её недостатком.
TestCafe внедряется в страницы в виде JS-скрипта, она не контролирует браузер, как это делает Selenium. Это позволяет TestCafe выполняться в любых браузерах, включая мобильные, и иметь полный контроль над тем, что происходит в JavaScript.
Библиотека TestCafe написана на JavaScript и ориентирована на тестирование. Она в настоящее время бурно развивается, хотя уже сейчас считается стабильной и имеющей достаточное количество возможностей. Рассмотрим её основные особенности:
▍Cypress
Cypress — это прямой конкурент TestCafe. Этот фреймворк работает практически так же, внедряя тесты в код страниц, но он пытается делать это более современным, гибким и удобным способом. Cypress новее, этот фреймворк недавно перешёл из стадии закрытой бета-версии в общедоступную бета-версию (в октябре 2017), но многие уже им пользуются. Вот основные особенности Cypress:
▍Puppeteer
Puppeteer — это библиотека для Node.js, которую разработала Google. Она предоставляет удобное Node.js API для управления браузером Chrome без пользовательского интерфейса.
Стоит сказать, что браузер Firefox также, в конце 2017-го, был выпущен с поддержкой работы в режиме без пользовательского интерфейса.
Обратите внимание на то, что различные инструменты для тестирования могут использовать Chrome и Firefox без пользовательского интерфейса. Например, это TestCafe и Karma.
Среди основных особенностей Puppeteer можно отметить следующие:
▍PhantomJS
PhantomJS использует движок Chromium для создания управляемого браузера без пользовательского интерфейса, похожего на Chrome.
С момента появления Puppeteer создатель PhantomJS, Виталий Слободин, прекратил работу над ним, в результате все процессы в сфере PhantomJS, с середины 2017, замедлились, хотя тут всё ещё наблюдается какое-то движение.
В каких ситуациях можно отдать предпочтение PhantomJS, если существует Puppeteer? Рассмотрим некоторые из них:
▍Nightmare
Nightmare — это отличная библиотека для тестирования пользовательского интерфейса, которая отличается очень простым синтаксисом тестов.
Nightmare использует Electron, что делает эту библиотеку похожей на PhantomJS, однако, тут применяется более новая версия Chromium и библиотека активно поддерживается и разрабатывается. Этому способствует и тот факт, что главная цель проекта Electron, который так же динамично развивается, заключается в создании кросс-платформенных настольных приложений на базе JavaScript, HTML и CSS.
Кроме того, сейчас ведутся обсуждения и производятся эксперименты, направленные на применение в Nightmare Chrome без пользовательского интерфейса. Взглянем на код тестов на Nightmare в сравнении с кодом на PhantomJS.
Вот код тестов на Nightmare:
Вот код тестов на PhantomJS:
▍Casper
Casper — это средство, созданное на основе PhantomJS и SlimerJS (это то же самое, что и Phantom, но тут используется Firefox Gecko). Casper позволяет имитировать взаимодействие пользователя с веб-страницами, даёт возможность написания скриптов и тестовых механизмов в абстрактном виде, поддерживает асинхронные возможности при создании скриптов для Phantom и Slimer.
Библиотека Slimer получила широкое распространение, хотя и считалась экспериментальной. В конце 2017-го года была выпущена её бета-версия, 1.0.0-beta.1, которая использует новый Firefox без пользовательского интерфейса. В настоящее время ведётся работа по устранению мелких недочётов и по выпуску первого релиза Slimer.
Возможно, в ближайшем будущем, с выходом второго релиза, Casper перейдёт с PhantomJS на Puppeteer и станет отличным инструментом для тестирования и в среде Chrome, и в среде Firefox. Полагаем, за этим проектом стоит понаблюдать.
▍CodeceptJS
CodeceptJS, как и рассмотренный выше CucumberJS, предоставляет дополнительный уровень абстракции над различными библиотечными API. Всё это направлено на то, чтобы разработчик взаимодействовал с тестами, основываясь на сценариях поведения пользователей.
Вот как выглядит работа с CodeceptJS:
А вот некоторые библиотеки, которые могут быть задействованы при выполнении этого кода: WebDriverIO, Protractor, Nightmare, Appium, Puppeteer. О них мы уже говорили.
Если вам кажется, что представленный выше синтаксис соответствует вашим нуждам, советуем опробовать CodeceptJS.
Итоги
Мы рассмотрели наиболее популярные инструменты тестирования веб-проектов. Что именно подойдёт для вас? Пожалуй, тут можно сказать, что лучшие архитектурные решения в сфере современных веб-приложений представляют собой комбинацию общих, проверенных временем шаблонов, выработанных сообществом разработчиков, и особенностей конкретного приложения. А найти то, что нужно для конкретного проекта, можно только одним способом: испытать всё, что кажется подходящим, на практике.
Уважаемые читатели! Чем вы пользуетесь для тестирования ваших JS-проектов?
Быстрая разработка скриптов мониторинга с помощью Bash, Outthentic и Sparrow
Доброе время суток!
Задача — у нас есть сервер, на который мы устанавливаем приложения и делаем настройку конфигурации. Хочется написать скрипт, который быстро даст нам ответ, что с сервером все хорошо, и приложение настроено и работает корректно. Этакий smoke тест, который будет нам полезен, когда мы будем заниматься поиском проблем или же просто проверять, что очередной деплоймент ничего не сломал. Предвидя возможные вопросы, я знаю, что уже существуют инструменты, которые делают что-то подобное ( inspec ), тем не менее, хочу рассказать об альтернативном походе. ( Будет интересно сравнить ).
Выбор инструментария
Итак, почему Bash? Потому что он достаточно прост в использовании и позволяет быстро и эффективно писать разного рода скрипты, imho я бы не стал использовать Bash для более сложных задач, но для данного рода проблем он вполне подходит.
Затем, что такое Outthentic и как он нам здесь пригодится? Outthentic — это фреймворк для написания скриптов, позволяющий быстро написать, настроить и запустить ваш скрипт ( в данном случае, написанный на Bash, но можно и на других языках ), так же, что немаловажно, Outthentic имеет встроенный DSL, подходящий под написание скриптов в стиле автоматизированных тестов, что может быть удобным при написании скриптов мониторинга.
И последнее — почему ( или что-то такое ) Sparrow и как он нам поможет? Sparrow — это платформа и среда выполнения пользовательских скриптов, позволяющая распространять и настраивать готовые скрипты в виде т.н. Sparrow плагинов. Основной выхлоп в том, что когда наш скрип написан и оттестирован, вы можете упаковать его в виде плагина, загрузить в Sparrow репозитарий и передать далее в отдел эксплуатации и/или любым другим коллегам, которые захотят воспользоваться вашим скриптом.
Практический пример
Пример отчасти основан на реальной практике, и отчасти сознательно упрощен, что бы не перегружать статью излишними деталями. Более-менее подобного рода проверки мне приходится делать постоянно, поэтому я и решил написать для них скрипт автоматизации, итак, будем проверять, что на целевом сервере target-server :
запущен tomcat, то есть виден в списке процессов
http запросы на некоторые ресурсы приложения ( развернутого на сервере )
возвращают успешный http код ( 200 ) — GET 127.0.0.1:8080/healthcheck
Да, и важно отметить, что все проверки выполняются прямо на целевом сервере:
Bash скрипт
В данном случае скрипт будет тривиальным:
Запустив скрипт на целевом сервере получим в выводе что-то похоже на это: ( на данном этапе пока никаких проверок не происходит, просто убедимся, что скрипт отрабатывает ):
Проверка вывода скрипта
Вся суть нашего мониторинга — возможность последовательного запуска нескольких команд и далее анализ их вывода с помощью набора простых правил, здесь и вступает в игру Outthentic.
Для начала установим пакет как CPAN модуль:
Далее слегка модифицируем наш скрипт, что бы его можно было запускать через Outthentic:
Получим вывод, аналогично тому, когда мы запускали скрипт напрямую. Пока, что польза Outthentic не очевидна. Доходим до использования DSL. Создадим несколько простых проверочных правил для валидации вывода скрипта и положим правила в файл story.check :
Запустим снова strun :
Мы видим, что проверочные правила сработали и, что вывод от скрипта успешно прошел все проверки, а это все что нам нужно от нашего мониторинга. Формат отчетов strun настраивается и имеет несколько вариантов, например, мы можем выбрать более лаконичный вывод, который выдаст всю детализацию, только в случае ошибки:
Вот как будет выглядеть отчет в случае если, по каким-то причинам, у нас не запущен tomcat сервер:
Параметризация скрипта мониторинга
Outthentic еще удобен и тем, что он позволяет просто добавлять и настраивать входные параметры для ваших скриптов. Допустим, чисто теоретически, мы захотим задавать хост и порт для сервера баз данных.
Добавим дефолтные значения входных параметров через suite.yaml — файл для хранения дефолтных настроек в терминологии Outthentic:
В данном случае иерархия конфигурационного файла может быть произвольной, просто я хочу показать, как легко и просто с помощью Outthentic передавать входные параметры, описанные в виде иерархический структуры данных и использовать их даже внутри Bash скриптов ( не применяя дополнительного парсинга ):
Чуть-чуть изменим скрип мониторинга, что бы он брал свои входные параметры из-вне :
Теперь мы можем запустить наш скрипт с дефолтными параметрами:
Или же переопределить параметры через командную строку:
Идем дальше, все что нам осталось сделать — это передать скрипт в эксплуатацию всем заинтересованным лицам, для этого нам понадобится Sparrow.
Дистрибуция скрипта в виде Sparrow плагина
Sparrow предоставляет две основные возможности дистрибуции скриптов — посредством публичного репозитария SparrowHub и посредством приватных репозитаиев, построенных на использовании удаленных репозиториях Git.
Скорее всего, когда мы пишем чисто внутренние скрипты, нам больше подходит второй способ. Он к тому же еще и более простой, так как требует только того, что бы исходники скрипта лежали в некотором удаленном Git репозитарии, что же сделаем это:
Добавив основные файлы проекта (story.bash и story.check ), нам остается настроить файл с мета данными ( который собственно и дает понять, что это не просто скрипт, а Sparrow плагин ) :
На самом деле файл с мета данными может содержать гораздо большее число параметров, но мы ограничимся здесь для простоты минимальным набором.
Окей, мы фактически сделали наш первый Sparrow плагин, осталось отправить файлы в git remote:
Использование готового скрипта мониторинга как Sparrow плагина
Это самая интересная часть в том смысле, что он показывает как Sparrow облегчает процесс установки и интеграции ваших скриптов сторонними командами.
Для начала, что бы использовать созданный нами плагин на каком-то целевом сервере, нам необходимо установить на этом сервере Sparrow клиент:
Далее все просто, т.к. плагин — приватный и не будет загружен с общего репозитариия, уведомляем об этом Sparrow:
Пара значений которую мы должны положить в локальный индексный файл
/sparrow.list это название плагина ( не обязательно должно совпадать с тем, что мы использовали в предыдущей части и URL удаленного репозитария, где лежит исходный код плагина )
Теперь обновляем индекс sparrow, что бы стал доступен добавленный нами плагин:
И устанавливаем сам плагин:
Теперь мы можем запустить плагин как есть:
Или же, передав ему параметры:
И наконец-то, все тоже самое можно запустить в виде Sparrow задачи:
Последний вариант запуска удобен тем, что вы можете создать несколько задач ( с разными конфигурациями ) для запуска одного и того же плагина. По сути задача — это именованная конфигурация запуска Sparrow плагина, а проект — группа задач.
На этом все. Если кому-то будет интересно, вот о чем я еще не сказал:
приватные Sparrow репозитарии можно настраивать не только через локальные индекс файлы
/sparrow.list ( что неудобно при большом количестве плагинов ), но и через Sparrow::Nest — API управления приватными Sparrow репозитариями.
Как всегда — вопросы, замечания, предложения, конструктивная критика — приветствуется.