На митапе Андрей Соколов из DINS расскажет, как разработчикам облегчить отладку с помощью Chrome DevTools. Константин Поздникин из Usetech покажет, как Cypress помогает бороться с багами в проектах со сложной бизнес-логикой. Во время прямого эфира вы сможете задать вопросы спикерам. Участие бесплатное, но нужно зарегистрироваться. Подробная программа и информация о спикерах под катом.

Программа

19:00-19:40 Инструменты отладки в Chrome DevTools (Андрей Соколов, DINS)

В Chrome DevTools есть много фишек, которые упрощают жизнь разработчиков. Андрей расскажет, как они могут сделать вашу отладку приятнее.

Вместе со спикером рассмотрим главные вкладки для отладки фронтенда: elements, console, source и network. Андрей расскажет о кнопках и функциях, которые вы видели, но не использовали.

Презентация будет полезна всем, кто взаимодействует с UI: фронтендерам, QA-инженерам, бэкенд-разработчикам.

Андрей Соколов Frontend Developer в DINS. Помимо работы увлекается написанием странных Telegram-ботов.

19:40-20:30 Cypress как ядерное оружие для багов на проекте со сложной бизнес-логикой (Константин Поздникин, Usetech)

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

В такой ситуации важно использовать интеграционное тестирование, тестирование API и unit-тесты для frontend, backend и их связки в окружении. Константин расскажет, как с этой задачей поможет справиться Cypress настоящее ядерное оружие в войне против багов. Вы узнаете, как с помощью Cypress заменить Selenium, экономить время и проводить комплексное эффективное тестирование.

Доклад будет интересен специалистам уровня Middle и выше.

Константин Поздникин ведущий разработчик компании Usetech. Преподаватель и ментор в Корпоративном университете компании.

Как присоединиться

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

Как проходят встречи

Записи предыдущих митапов можно посмотреть на нашем YouTube-канале.

О нас

DINS IT EVENING это место встречи и обмена знаниями технических специалистов по направлениям Java, DevOps, QA и JS. Несколько раз в месяц мы организуем встречи, чтобы обсудить с коллегами из разных компаний интересные кейсы и темы. Открыты для сотрудничества, если у вас есть наболевший вопрос или тема, которой хочется поделиться пишите на itevening@dins.ru!

В этой статье вы узнаете:

• Что такое Cypress и когда его стоит использовать

• Основы тестирования с использованием Cypress

• Расширенные команды Cypress

• Взаимодействие с элементами пользовательского интерфейса

• Лучшие практики с использованием Cypress

Введение

Чтобы протестировать свои приложения, вам потребуется сделать следующие шаги:

• Запустить приложение

• Подождать пока сервер запустится

• Провести ручное тестирование приложения(нажать на кнопки, ввести случайные текст в поля ввода или отправить форму)

• Проверить, что результат вашего теста корректен(изменения заголовка, части текста и т.д.)

• Повторить эти шаги ещё раз после простых изменений кода

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

Именно здесь в игру вступает Cypress. При использовании Cypress единственное, что вам нужно сделать, это:

• Написать код вашего теста(нажатие на кнопку, ввод текста в поля ввода и т.п.)

• Запустить сервер

• Запустить или перезапустить тест

Только и всего!Библиотека Cypress выполняет все тесты за вас.И самое приятное, что она не только сообщает вам все ли ваши тесты успешны или нет, но также сообщает вам, какой тест не удался.

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

Теперь, когда мы обсудили преимущества Cypress, давайте узнаем об основах этой библиотеки.

Начало

Установка и настройка Cypress

Сначала создайте отдельную папку для вашего проекта, а затем инициализируйте ее:

Наконец, чтобы установить библиотеку Cypress:

Примечание. Если вы используете дистрибутив Linux, перейдите кэтим инструкциям,прежде чем продолжить установку Cypress через NPM.

Теперь, когда Cypress установлен, попробуйте запустить его с помощью следующей команды:

Она открывает запускалку тестов(Test Runner):

А теперь давайте перейдём к написанию тестов.

Основы Cypress

Создание файла

Cypress требует, чтобы все наши тесты находились вкаталоге cypress/integration.Сначала перейдите в этот каталог:

Теперь создайте файл JavaScript с именемbasicTest.js:

Если вы не отключили сервер Cypress, ваши новые файлы появятся в Test Runner в реальном времени:

Теперь давайте напишем наш первый тест.

Простые тесты с утверждением и ожиданием значения

В вашем файле /cypress/integration/basicTest.js напишите следующий код:

• Строка 1:Функция describe сообщает Cypress название набора наших тестов.

• Строка 2: Функцияit, обозначает название теста.

• Строка 3: Создаём утверждение.Здесь мы подтверждаем, что 2 + 2 равно 4. Если тест вернётfalse, то он будет немедленно остановлен.

Чтобы запустить вашу программу, щёлкните поbasicTest.js в вашем сервере Cypress.

Результат запуска:

Отлично!Значит, наше утверждение было успешным.

Что, если мы сделаем заведомо ложное утверждение?Теперь в/cypress/integration/basicTest.js добавьте следующий код впределах функцииdescribe:

• Строка 2: Если сумма 4 и 5 равна 10, тест будет пройден. В противном случае, незамедлительно остановлен.

Снова запустите код.Результат будет:

Обратите внимание, как наш второй тест не удался.Если бы результат был правильным, тест прошел бы успешно.

Давайте больше поиграем с утверждениями.Добавьте в basicTest.jsследующий код:

• Строка 2: Если сумма 5 и 5неравна 100, то тест должен пройти.

Результат выполнения теста:

Отлично!Наш тест прошел. Функцияexpect выполняетBDD (behavior-driven) утверждения.В следующем разделе мы выполним утверждения, основанные на тестировании(test-driven assertions).

Сейчас/cypress/integration/basicTest.jsдолжен выглядеть так:

Написание утверждений основанных на тестировании(test-driven assertions) с явным использованием assert

Мы даже можем писать утверждения на основе TDD с использованиемassert.

В вашем файлеbasicTest.js напишите следующий код:

• Строка 2: Создаём объект со свойствамиnameи age.

• Строка 6: ФункцияisObjectподтверждает,что переменнаяpersonявляется объектом.Если результатtrue, то будет напечатаноvalue is object.В противном случае будет показано, что этот тест не прошел.

• Строка 10: Убеждаемся, что переменнаяnameсодержитстроковое значение.

• Строка 14: Убеждаемся, что переменнаяname неявляется целым числом.

Запустите код.Результатом будет:

Отлично!Наш код работает.В следующем разделе мы научимся работать с сайтами через Cypress.

Сейчас нашbasicTest.jsдолжен выглядеть так:

Запуск веб-сайтов

Здесь мы попробуем запуститьDemoblaze, сайт, созданный для проведения тестов.

В своей папке/cypress/integration/ создайте файл с именемbasicCommandsTest.js.В этом файле напишите следующий код:

• Строка 3: Используем методvisit, чтобы сообщить Cypress о переходе на веб-сайт Demoblaze.

Сохраните свой код и нажмите наbasicCommandsTest.js в меню Test Runner:

Результат запуска:

Отлично!Наш код работает.В следующем разделе мы более глубоко погрузимся в тестирование с помощью Cypress.

В итогеbasicCommandsTest.jsдолжен выглядеть так:

Cypress: Расширенные команды

В этом разделе мы попытаемся взаимодействовать с элементами на странице.Однако, прежде чем продолжить этот процесс, нам нужно сначала научиться идентифицировать элементы HTML в Cypress.

Как идентифицировать элементы

Cypress используетселекторы JQueryдля идентификации компонентов на веб-странице.

Например, чтобы получить элемент myButton используя id, мы должны написать следующий код:

В качестве альтернативы, чтобы идентифицировать элемент myButton используя имя класса, могли бы использовать следующую строку:

Давайте теперь поработаем с взаимодействием с пользовательским интерфейсом нашего сайта.

Нажатие кнопки

В этом разделе мы будем использоватьстраницу The-Internetдля запуска наших тестов.На этом веб-сайте мы будем использоватьразделдобавления/удаленияэлементов.

Давайте сначала попробуем идентифицировать нашу кнопку Добавить элемент.

Используя DevTools, заметьте, что уbuttonесть свойствоonclick, имеющее значениеaddElement().

Соответствующий селектордля этой кнопки будет выглядеть так:

В папке/cypress/integration создайте файл с именемrunningClickCommand.js.В этом файле напишите следующий код:

• Строка 2: Переходим на веб-страницу.

• Строка 6: Связываем в одну цепочку получение элемента button и нажатие на эту кнопку.

Запустите код.Результат:

Отлично, наш код работает!Обратите внимание, что как только страница загрузилась, в нашем тесте автоматически происходит нажатие на кнопкуAdd Element.

Давайте теперь поработаем с вводом текста в текстовое поле.

Ввод текста

В этом разделе мы будем использоватьстраницуThe-Internets login.Нам нужен способ сначала идентифицировать элементы.

Поле username имеетid равноеusername, а полеpassword имеетid равноеpassword.Кроме того, кнопка Login имеет свойствоtype равноеsubmit.Таким образом, для определения полейusername иpassword, нам понадобитсяселектор JQuery id:

Более того, чтобы получить кнопкуbutton, нам понадобитсяселектор атрибутов, например:

В своей папке/cypress/integration создайте файл с именемrunningTypeCommand.js.В этом файле напишите следующий код:

• Строка 3: Переходим на страницу входа в систему.

• Строка 6: Переходим в полеusername и добавляем методtype вцепочку вызовов, чтобы напечатать в этом текстовом поле значениеtomsmith.

• Строка 7: Переходим в полеpassword и вводимSuperSecretPassword.

• Строка 10: Нажимаем на кнопку Отправить.

Запустите код.Результатом будет:

И мы закончили!В следующем разделе мы узнаем о работе с чекбоксами.

Переключение чекбоксов

В этом разделе мы будем использоватьраздел чекбоксов на странице The-Internet.

Давайте сначала посмотрим на DevTools:

Оба этих чекбокса имеют свойствоtypeсо значениемcheckbox.Кроме того, они также являются дочерними элементамидля элементаform сid равнымcheckboxes.В этом случае мы бы использовалиселектор JQuery родитель-потомок:

В каталоге/cypress/integration/ создайте файл с именемrunningCheckCommand.js и напишите следующий код:

• Строка 4: Находим обе группы чекбоксов, а затем используем методcheck, чтобы отметить их выбранными.

• Строка 7: Просим Cypress приостановить процесс тестирования на одну секунду.

• Строка 8: Получаем список отмеченных чекбоксов.Затем используем методuncheck, чтобы снять выбор.

Запустите код.Результат:

Отлично!Наш код работает.Давайте теперь поработаем над неявными утверждениями с помощью Cypress.

Неявные утверждения

Ранее мы выполняли утверждения для переменных и объектов.Однако в реальном мире мы хотели бы выполнять утверждения для текста, расположенного в нашем элементе HTML, или проверять, есть ли у нашего элементаul дочерние элементыli или нет.

Для выполнения таких утверждений мы будем использовать ключевое словоshould.В этом разделе мы будем делать неявные утверждения настраницедобавления элемента The-Internets Add Element

Наша кнопкаDelete имеет классadded-manually.Мы хотим выполнить следующее утверждение для этого элементаbutton:

Для этого мы должны использовать следующий синтаксис:

Альтернативно, можем выполнить такое утверждение:

Мы можем использовать эту строку кода:

Перейдите в/cypress/integration/runningClickCommand.jsи добавьте следующий код:

• Строка 1: Получаем элементы с классомadded-manually.Затем проверяем, что их количество(have.length)равно единице.

• Строка 3: Получаем кнопкуAdd Element, а затем проверяем, что текст на кнопке(have.text)действительно будетAdd Element.

Запустите код.Результат в конце теста должен быть следующим:

Отлично!Наш код работает.Теперь перейдем к изучению командыeach.

В итогеcypress/integration/runningClickCommand.js должен выглядеть так:

Команда each

Взглянитееще раз наThe-Internets Add Elements page:

Чтобы удалить все эти элементы, мы можем вручную прокликать все кнопкиDelete.Это возможно;однако рассмотрим ситуацию, когда кнопокDeleteбольше сотни.Следовательно, удаление всех их вручную займет много времени.

Вот здесь-то и появляется командаeach. Она позволяет вам перебирать серию элементов, а затем выполнять любую функцию для каждого из них.В этом случае мы хотим перебрать все наши кнопкиDelete и запустить функциюclick на всех них.

Откройте Developer Tools:

Все наши кнопкиDelete имеют свойствоclass равноеadded-manually.В этом случае мы будем использоватьселектор классови соединять его с командойeach, например:

Перейдите в/cypress/integration/runningClickCommand.jsи добавьте следующий фрагмент кода:

• Строка 2: Получаем все элементы, у которых есть класс.added-manually.Каждый элемент в серии будет представлен параметром$el.

• Строка 3: Обёртываем этот элемент, чтобы мы могли выполнять с ним команды Cypress.Здесь мы отправляем команду щёлкнуть по этим элементам.

Результат выполнения кода должен быть следующим:

Наш код работает!Поскольку наш тест был быстрым, давайте попробуем добавить на страницу больше элементов.

Найдите следующий фрагмент кода:

Измените это так:

• Строка 2: Запускаем цикл, чтобы сообщить Cypress, что нужно нажать кнопкуAdd Element 20 раз.

Запустите код еще раз.Результат должен быть таким:

Как видите, наша программа автоматически удалила все элементы на странице без каких-либо ручных усилий.Отлично!

В следующей части статьи мы узнаем о том, что можно и чего нельзя делать при тестировании с Cypress.

В итогеcypress/integration/runningClickCommand.jsдолжен выглядеть так:

Лучшие практики

Держите тесты изолированными

Рассмотрим ситуацию, когда вы тестируете свое приложение.Структура вашего проекта будет выглядеть примерно так:

В вашем Test Runner это будет выглядеть так:

Команда Cypress утверждает, что структура вашего проекта должна быть организована как можно лучше.Лучше всего перегруппировать ваши файлы проекта в другие папки, например:

Следовательно, это выглядело бы так:

По возможности используйте собственные команды

Взгляните на этот фрагмент кода:

Обратите внимание, что мы вынужденымногократноиспользоватькомандыgetиtype.Здесь мы можем реализоватьсобственные команды,чтобы сделать их короче.

В вашемcypress/support/commands.jsнапишите этот код:

• Строка 1: Создаём собственную команду, которая будет иметь два параметраidentifier иdata.

• Строка 2: Получаем элемент с соответствующим идентификатором, а затем вводим в него данные.

Примечание. Считается хорошей практикой записывать свои собственные команды в файл/cypress/support/commands.js.

Теперь вернитесь в свой тестовый файл и замените его вот так:

Как видите, наш код выглядит значительно короче.

Избегайте атомарных тестов

Взгляните на этот фрагмент кода:

Здесь мы повторно выполняем тесты на HTML элементе сid равнымfirst.

Cypress не одобряет такого поведения.Это неэффективно, и есть способ лучше переписать этот код, например:

Мы можем использовать методand для связывания дополнительных командshould с нашим элементом.

Не запускайте сервер в Cypress

Команда execприсутствует для запуска команд в терминале.Но запускать сервер с помощью этой команды крайне не рекомендуется.

Если вы хотите протестировать свое приложение наlocalhost, сначала запустите сервер,а затемзапустите свой тест Cypress.

Репозиторий GitHub и дополнительные ресурсы

Код GitHub

• Код этого проекта

Дальнейшее чтение

• Cypress Tutorial Videos

• End-To-End Testing With Cypressby codedamn

• Real Confidence With Cypress

• Best practices with Cypress: AssertJS Conference

Заключение

Тестирование ключевой шаг в процессе разработки, поскольку он обеспечивает правильную работу вашего приложения.Некоторые программисты предпочитают вручную тестировать свои программы, поскольку написание тестов требует значительного количества времени и энергии.К счастью, Cypress решил эту проблему, позволив разработчику писать тесты в короткие сроки.

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

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

Введение в Cypress

Если отбросить капитанское определение, что Cypress это JavaScript-фреймворк для тестирования, то важно отметить, что при работе с ним мы видим на экране браузер. Он не обязательно открыт, он может быть headless, но он есть, и он открывает особое приложение самого Cypress, которое состоит из нескольких фреймов: в одном фрейме открывается продукт, который мы тестируем, в другом фрейме запускаются тесты. Код тестов пишется на JavaScript, поэтому они могут выполняться непосредственно в браузере ведь это нативный для него язык.

Так с помощью JavaScript API производятся все манипуляции, которые делаются в тестах, то есть заполнение форм, клики и тому подобное.

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

Нет Selenium WebDriver

Очевидное отличие Cypress от тех библиотек и фреймворков, которые мы использовали раньше это отсутствие основного действующего элемента, Selenium.

Selenium WebDriver это third-party сервис на Java, который обращается к браузеру по WebDriver протоколу. Это накладывает ограничения на работу с браузером в рамках протокола. Сетевое взаимодействие также вносит свой вклад во время выполнения тестов.

Изначально Selenium был создан не специально для тестов, а как общий инструмент автоматизации для браузера. Cypress, в отличие от него, сфокусирован на решении конкретной задачи, а именно, на создании end-to-end (е2е) тестов для интерфейса web-приложений.

Все в одном

Cypress не нужно собирать из кусочков он принес все достаточно современные "батарейки" с собой:

• Синтаксис BDD (унаследовано из Mocha): describe(), context(), it().
  А также хуки: before(), beforeEach().
  Использовать такой DSL привычно для тех, кто уже писал юнит-тесты на JavaScript.

• Библиотека ассертов (унаследовано из Chai). Например:
  expect(name).to.not.equal("Jane") ожидание того, что элемент не существует это не то же самое, что ожидание неудачи при проверке существования элемента. Если элемента нет, то это хорошо, это не нужно перепроверять, а нужно идти дальше.
  Такую задачу должен решать тестовый фреймворк, и этого нам очень не хватало в старой самописной библиотеке, при использовании которой многое ложится на плечи разработчика теста.

• Перехват, отслеживание (spy) и подмена (mock) запросов браузера к бэкенду.

Development experience

Главное преимущество Cypress это отличный development experience. Написать первый тест для своего проекта (неважно, на каком языке написан сам проект) можно минут за 10. Потребуется добавить одну зависимость в package.json (npm install cypress), прочитать документацию про то, куда складывать файлы (cypress/integration/login.spec.js), и написать код в 5 строчек:

describe('Login', () => {it('should log in with credentials', () => {cy.visit('/login');cy.get('[name=login_name]').type(Cypress.env('login'));cy.get('[name=passwd]').type(Cypress.env('password'));cy.get('[name=send]').click();cy.get('.main-header').should('be.visible');});});

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

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

Приятной мелочью является то, что каждый cy.get() убеждается, что страница загрузилась, и делает несколько попыток, чтобы найти элемент. С каждым годом интерфейсы веб-приложений становятся все сложнее. Результирующий HTML формируется не на стороне сервера, а на стороне браузера. Делается это асинхронно и с использованием различных библиотек компонентов. В какой момент тот или иной элемент интерфейса появится на экране, сказать уже становится сложнее.

Одна из Best Practices говорит, что не нужно никогда писать таймаут типа "подождать 2 секунды". Абсолютно все таймауты должны ждать чего-то осязаемого, например, окончания Ajax-запроса. Можно подписаться на событие, которое случается в коде продукта. Например, когда нам через веб-сокет прилетает событие с бэкенда, то срабатывает определенный listener на фронтенде.

Вся документация Cypress и Best Practices находятся на одном сайте docs.cypress.io хотелось бы отдельно отметить высокое качество этой документации, а также мастер классов, которые команда разработки Cypress проводит и публикует в открытом доступе.

Кроме того, один из паттернов, от которых стоит отказаться это PageObject. Долгое время он считался обязательным, но для новых тестов он нам уже не понадобится.

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

Тестовая пирамида

Когда говорят про тестовую пирамиду, то обычно приводят в пример анти-паттерн "перевернутая пирамида" или "стаканчик мороженого". То есть на нижнем уровне в таком примере количество юнит тестов стремится к нулю. Лично мне этот случай кажется невероятным для зрелого проекта: ведь в этом случае разработчики должны были полность отказаться писать самые простейшие тесты откуда тогда взялись сложные е2е тесты?

Как бы то ни было, к нам это не относится у нас несколько тысяч PHPUnit-тестов с покрытием около 12% строк кода.

В то же время у нас есть еще несколько тысяч е2е-тестов с Selenium, которые проверяют все возможные конфигурации продукта, занимают кучу времени (подмножество, запускаемое на каждый коммит, мы смогли оптимизировать до 40-60 минут), имеют довольно слабый уровень доверия (с вероятностью 30-40% тесты упадут, хотя коммит не содержит причины этого падения) и покрывают около 30% строк кода.

Получается, наше положение выглядит, как песочные часы нам не хватает среднего слоя в тестировании, где интеграционные тесты проверяют компоненты системы независимо друг от друга. Это горлышко песочных часов и хочется заполнить с помощью Cypress. При этом еще хочется что-то сделать с существующими е2е тестами, чтобы "заострить" вершину пирамиды. То есть, важный акцент здесь в том, что Cypress не является заместителем старого фреймворка: мы не хотим просто взять и переписать все тесты на Cypress иначе мы так и останемся на шарике мороженого. Цель тестов по-прежнему, проверять регрессию в продукте, но проверять на другом уровне, чтобы выполняться быстрее и получать результат раньше, а также быть легче в сопровождении.

Наш подход к написанию тестов

Проект, о котором идет речь, это контрольная панель Plesk. Она предоставляет пользователям интерфейс для управления хостингом веб сайтов. Функциональность панели доступна не только через UI, но и через API и CLI, которые используются для автоматизации.

Мы начали с того, что сделали следующие предположения:

• Тесты на Cypress относятся чисто к UI. Мы не относим сюда тесты, у которых шаги выполняются через API или CLI.

• Мы не проводим никакой дополнительной валидации, кроме той, что выполняется средствами UI. Например, если мы проверяем создание домена, то мы не отправляем запросы для проверки Web-сервера или DNS, мы считаем тест пройденным, если в UI появилось сообщение на зеленом фоне о том, что домен создан успешно. Такой подход избавляет нас от предварительной подготовки и написания тестовых сценариев.

• На первом этапе мы автоматизируем только позитивные сценарии. Негативные сценарии не представляют ценности для клиента, но при этом тесты для их проверки занимают драгоценное время. Так что переносим такие сценарии в нижнюю часть пирамиды они, как правило, легко проверяются юнит-тестами.

Наш опыт работы с Cypress в сочетании с официальными рекомендациями привел нас к использованию следующего набора практик:

Сбрасывать состояние продукта

Мы сбрасываем состояние продукта до исходного перед запуском каждого набора тестов (Cypress рекомендует делать это перед запуском каждого теста, но мы используем облегченный вариант). Мы создаем дамп базы данных и восстанавливаем его перед прогоном каждого набора тестов (test suite / spec). Это занимает порядка 5 секунд.

before(cy.resetInstance);//=> test_helper --reset-instance//=> cat /var/lib/psa/dumps/snapshot.sql | mysql

Такой откат к прежнему состоянию может в общем случае привести Plesk в нерабочее состояние, т.к. помимо общей базы есть еще, например, базы отдельных утилит, а также бэкапы, которые хранятся в файловой системе. Но нас это устраивает, т.к. мы используем Cypress только для тестирования UI.

Использовать фикстуры

Вместо реальных объектов в качестве пререквизитов теста мы используем фикстуры сохраненные структуры, которые содержат необходимое состояние базы данных. Например, для выполнения некоторых тестов необходимо наличие домена. Вместо создания реального домена мы воссоздаем все необходимые записи в базе данных, но не трогаем файловую систему и другие системные сервисы. Это занимает меньше секунды (для сравнения, создание полноценного домена заняло бы около 30 секунд).

cy.setupData(subscription).as('subscription');//=> test_helper --setup-data < {domains: [{ id: 1, name: "example.com" }]}

Такие объекты не будут выполнять полноценные пользовательские сценарии, но для тестирования UI их будет достаточно.

Использовать прямые URL

Мы не используем навигацию и попадаем в нужные места UI по прямым URL-ам. Мы вызываем свою специальную команду login, которая создает сессию, а затем переходим прямо на нужную страницу.

beforeEach(() => {cy.login();cy.visit('/admin/my-profile/');});

В старом фреймворке мы бы использовали PageObject для входа в главное меню, а затем переходили бы из него к нужному элементу. Здесь же этого не требуется, так как мы тестируем только необходимую страницу. Единственное дублирование это команда login, но это не выглядит проблемой.

Фронтенд без бэкенда

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

const lastChecked = 'Jan 29, 2021 04:42 PM';cy.intercept('POST', '/admin/home/check-for-updates', {status: 'success',lastChecked,newVersion: null,whatsNewUrl: null,}).as('checkForUpdates');cy.get('[data-name="checkForUpdates"]').click();cy.wait('@checkForUpdates');cy.get('[data-name="lastCheckedDate"]').should('contain', lastChecked);

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

Стабильность тестов

Скорее всего, когда вы начнете писать Cypress тесты, то каждый второй тест будет неожиданно становиться flaky, то есть иногда проходить, а иногда нет. Чтобы избежать такой нестабильности, мы используем следующие практики.

Дожидаться выполнения Ajax-запроса

Многие формы в нашем продукте отправляются с помощью Ajax-запросов без перехода страницы. Чтобы тест гарантированно прошел, необходимо перехватить этот запрос и дождаться его завершения. Так как в Cypress мы проверяем только то, что происходит в UI, мы дожидаемся нужного нам сообщения.

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

cy.intercept('POST', '/admin/customer/create').as('customerCreate');cy.get('[name=send]').click();cy.wait('@customerCreate');cy.get('.msg-box.msg-info').should('be.visible');

Дожидаться исчезновения индикатора загрузки

Кое-где в нашем интерфейсе фоновые операции, например, обновление списка, сопровождаются анимированным индикатором загрузки ("крутилкой"). Именно на таких страницах после окончания Ajax-запроса случается ошибка "element has been detached from the DOM" при попытке Cypress кликнуть на элементы списка. Поэтому мы добавляем после Ajax-запроса дополнительную строку, которая проверяет, что индикатор загрузки не виден.

cy.get('.ajax-loading').should('not.be.visible');

Мы надеемся, что проблема будет исправлена на стороне Cypress и нам больше не придется за этим следить.

Ajax-запросы после окончания теста

После окончания каждого теста браузер остается на последней открытой странице. Cypress сбрасывает состояние браузера (включая куки) и запускает следующий тест, где первым шагом мы сбрасываем состояние продукта (включая сессии бэкенда).

До того момента, когда следующий тест сделает первый вызов "cy.visit()", предыдущая страница остается открытой и может отправлять Ajax-запросы (например, периодическое обновление), которые будут падать из-за ошибки авторизации (куки нет, сессии нет).

В качестве workaround можно переходить на пустую страницу, чтобы браузер сбрасывал все активные Ajax-запросы. Для этого добавляем в support/index.js

afterEach(() => {cy.window().then(win => {win.location.href = 'about:blank';});});

Первые результаты

За 3 человеко-месяца (3 итерации) мы получили следующие результаты:

• 335 тестов на Cypress (разбиты на 84 спеки)

• Пайплайн полностью выполняется за 35-40 минут, из которых сами тесты занимают 20 минут

• Запуск пайплайна на каждый пулл-реквест в блокирующем режиме (то есть нельзя мержить без успешного прохождения тестов)

• Уровень доверия выше 95% (то есть вероятность flaky падения ниже 5%)

• Покрытие интерфейса 35% (ниже расскажу подробнее)

Пайплайн для запуска тестов

За время разработки пайплайн для запуска тестов прошел несколько этапов развития. Требованием было уложиться в час, иначе ожидание мержа в пулл реквесте слишком затягивается.

Как и для большинства наших задач, пайплайн запускается в Jenkins и хранится в Jenkinsfile вместе с кодом проекта.

Линейный пайплайн

В первом заходе получился простой линейный пайплайн.

Мы запускаем Docker-контейнер с Plesk в фоновом режиме и ждем, когда он будет доступен в локальной сети. Потом запускаем другой контейнер с Cypress и кодом тестов, он подключается к Plesk и выполняет все тесты, а мы ждем его завершения (не делаем detach).

Мы запускали тесты на машине с 12 ядрами, которая используется у нас для сборки Plesk и ряда его служб. В течении рабочего дня у нас бывает до 20-30 сборок. В результате Load Average достигал 20, и многие соседние процессы "вставали". Мы добавили ограничение на количество исполняемых сборок до 3-5. Но и этого оказалось недостаточно, соседи по железу продолжали жаловаться на нагрузку.

Тогда мы унесли запуск тестов на выделенный сервер в AWS с 4 ядрами внутри VPC с доступом в нашу офисную сеть. Тем самым мы избавились от недовольных соседей, но сборки тестов так и продолжили подолгу ждать в очереди, время от времени не укладываясь в таймаут.

Пайплайн с параллельными шагами

Чтобы как-то ускорить процесс, мы решили воспользоваться Jenkins EC2 Fleet plugin, который предоставляет Jenkins slave ноду по требованию из Autoscaling Group в AWS и уничтожает неактивные ноды после некоторого простоя. Такой подход позволяет тратить деньги на аренду ресурсов только тогда, когда они необходимы.

Переход на spot-инстансы позволил нам существенно сэкономить: вместо $150 в месяц за ondemand c5.xlarge, мы стали тратить около $60 за c5.xlarge и более мощные c5.2xlarge.

А главное, мы можем делать столько одновременных запусков, сколько нам нужно.

Разворачивание новой ноды занимает порядка 2 минут. Мы сделали в пайплайне несколько шагов параллельными, чтобы за это время успеть собрать продукт и быть готовыми к его установке в Docker на новой ноде.

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

Пайплайн с параллельными тестами

В Cypress есть платная фича параллельный запуск тестов с помощью Cypress Dashboard. Но мы пошли простым и бесплатным путем перечисляем файлы с тестами при запуске контейнера, при этом первый запускает все четные файлы, второй все нечетные.

cypress run --spec $(find 'cypress/integration' -type f -name '*.js' | awk '(NR - ${RUNNER}) % ${TOTAL_RUNNERS} == 0' | tr '\n' ',')

Получилась матричная сборка, где для каждой оси (axis) запускается свой контейнер с Plesk и свой контейнер с определенным набором тестов.

В итоге мы укладываемся в приемлемые 35-40 минут для всего пайплайна, а время одной пачки тестов занимает примерно 20 минут.

В дальнейшем с увеличением количества тестов нам, очевидно, потребуется больше параллельных потоков, и мы планируем использовать Amazon ECS для запуска контейнеров, чтобы не ограничиваться EC2 инстансом.

Измерение URL coverage

В нашем проекте используется много различных языков программирования и анализ code coverage является больной темой, потому что сбор данных требует специальных билдов и объединения отчетов с нескольких конфигураций.

Для анализа тестового покрытия UI мы решили воспользоваться продуктовой аналитикой и сравнить данные, полученные от тестовых инсталляций, с данными от реальных пользователей. У нас уже был сервис, аналогичный Google Analytics, для сбора пользовательских метрик, а тестовые данные складывались отдельно и никем не использовались. Из множества метрик мы отфильтровали события о посещенных URL-ах (страницах) продукта, начали сохранять эти данные в удобном для нас виде в базу данных и составлять отчет по посещенным адресам.

По полученным данным, за счет всего автоматического и ручного тестирования внутри компании мы покрываем около 60% URL-ов, которые посещают реальные пользователи в течении месяца. Наши старые тесты покрывают около 25%, а новые тесты на Cypress уже достигли 35%.

Эта статистика помогает нам планировать дальнейшее тестирование например, более посещаемые страницы мы планируем автоматизировать в первую очередь.

Следующие шаги

Ускорить сборку Docker

Одна из проблем, над которой мы хотим поработать ускорение сборки контейнеров Docker. Как уже было сказано выше, мы создаем временный сервер в AWS (slave node) для каждой сборки Docker, и эта сборка на данный момент занимает в среднем 8 минут. Но поскольку каждый временный сервер новый, то мы совершенно не используем преимущества кэширования, а хотелось бы ими воспользоваться. Поэтому сейчас мы исследуем возможность использования BuildKit. Альтернативными решениями могут стать Kaniko или AWS CodeBuild.

Сократить количество е2е тестов

Мы хотим уменьшить количество старых е2е тестов, чтобы вершина тестовой пирамиды стала более острой. Сейчас около трети этих тестов относятся к UI. Кроме этого, тесты содержат проверки через командную строку (CLI), причем иногда логика тестов в UI и CLI дублируется.

Основная идея: перенести все UI-тесты в Cypress, а в старом фреймворке оставить только CLI-тесты с детальными проверками. Поэтому для каждого UI-теста из старого фреймворка мы делаем следующее:

1. Заменяем UI-шаги на CLI (если это возможно).

2. Удаляем, если уже есть аналогичный тест с CLI.

3. Если проверка возможна только через UI уносим ее в Cypress.

Например, при создании домена проверяется то, что он резолвится, и что на нем работают определенные скрипты. Эти проверки останутся только для создания домена через CLI. А тест на UI в Cypress будет проверять только появление сообщения о создании домена.

В результате мы избавимся от дублирования тестовых сценариев, сократим нагрузку на сервера с Selenium и в перспективе совсем от них избавимся, когда тестирование UI будет делать только Cypress.

Заключение

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

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

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

У меня есть друг, который говорит, что если посчитать количество часов потраченное на изготовление этого прибора, то дешевле купить самый дорогой. Я конечно с ним не согласен, но не буду долго останавливаться на этой провокационной теме. Скажу лишь, что по времени, разработка и изготовление этого прибора заняла около 30 часов. Я использовал детали которые были у меня в наличии, в том числе датчик влажности, был куплен только аккумулятор. Для меня подобные проекты нужны ещё за тем, чтобы прокачать навыки, узнать что то новое, и получить прибор на свой вкус.

Прибор нужен был автономный, с временем автономной работы около 12 часов. Соответственно схема питания USB-> контроллер заряда -> повышающий преобразователь до +5 В. Питание выбрал 5 В, так как датчик влажности, имеющийся в наличии (HIH-4010-004), калиброван при питании 5 В. При покупке к датчику прилагалась распечатка, со всеми константами для расчета RH% по выходному напряжению, для достижения точности измерения влажности 3.5%.

Тема датчиков влажности - это отдельная тема.Если коротко, оказалось что они очень нежные. На HIH-4010-004 в datasheet есть запись, что долгая эксплуатация при влажности более 90% может привести к сдвигу показаний на 3% . А вот для более новых датчиков HDC2080 от TI указано, что рекомендуемый диапазон влажности для работы, от 20% до 80% при температуре воздуха от 0 до 60. Если долго эксплуатировать датчик за пределами этого диапазона, то используемый в датчике полимер будет деградировать, и показания будут сдвигаться с долгим временем восстановления.

В 2014 году Cypress устроил промо, на микроконтроллеры PSOC 4200 можно было купить за $1 с бесплатной доставкой, в том числе и в Россию. И я не устоял и прикупил пару десятков в QFP корпусе и десяток в SSOP.

Микроконтроллеры примечательны тем, что помимо Cortex-M0, 32KB EEPROM и 4K RAM. У них на борту присутствовало четыре UDB блока (вариант программируемой логики), в каждом из которых было два PLD (Programmable Logic Device) и 8 битное ALU с возможностью выполнять до 8 команд в цикле, работающий на тактовой частоте процессора 48 МГц. Так как в своих прошлых проектах часто надо было городить мелкую логику вокруг контроллера, тема UDB меня привлекла.

Также на борту микроконтроллера был необычный контроллер LCD, он позволял управлять мультиплексными LCD индикаторами, не как обычно, а используя для формирования напряжения смещения резистивные делители, а используя ШИМ, а для LCD с количеством разрядов до 4 - Цифровую Корреляцию.

Как оказалось изображение получается достаточно контрастным, в данном приборе применил регулировку контрастности в зависимости от температуры. Всего 3 ступени, меньше 0, от 0 до 30 и больше 30.

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

По программе, работа с датчиком DS18B20 организована через UART в прерывании, поэтому пришлось тактовую частоту микроконтроллера сделать 24 МГц, чтобы получить целые делители для скоростей 9600 и 115200. Разница в потреблении на 6 МГц и 24 МГц - 4 мА. Наверное можно было как то выкрутиться и сделать минимальную тактовую частоту, но я не стал возиться, так как для данного прибора не предполагалось долгой автономной работы.

Преобразование измеренного напряжения датчика влажности в RH% сделано в целых числах, с учетом напряжения питания и температурной компенсацией. В моем случае напряжение на выходе повышающего преобразователя оказалось 5.16 В. По этой причине, и по причине того, что у каждого датчика HIH-4010-004 свои калибровочные константы, прошивка для микроконтроллера не Git не размещена. Так как среда разработки PSOC Creator абсолютно бесплатная, а скомпилировать прошивку можно с помощью GCC компилятора, это не должно стать проблемой.

В приборе не предусмотрен тумблер включения питания, поэтому я старался предусмотреть все возможные отказы, в том числе замыкал пинцетом выход DS18B20 на землю. В программе сделал как обработку ошибок в прерывании, так и перезапуск UART по тайм ауту и естественно использовал Watch Dog таймер на случай непредвиденных зависаний самого микроконтроллера.

Напряжение батареи отображается угловым знаком подчеркивания под каждым разрядом, диапазон 3 - 4.2 вольта по 0.15 вольта на каждый сегмент.

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

При длительном нажатии единственной кнопки или спустя 60 минут после включения, микроконтроллер уходит в режим STOP . Микроконтроллер потребляет в режиме STOP всего 80 нА. Так как в режиме STOP у микроконтроллера выходы замораживаются , контроллер LCD заранее отключаем, а на выводе ENABLE импульсного стабилизатора устанавливаем 0, тем самым отключаем стабилизатор и датчики.

И немного техно обнаженки.

Сразу хочу сказать, что я чистюля, и мою платы в изопропиловом спирте по нескольку раз. Но с этой платой случай особый, во-первых стекляшка LCD не любит растворители, во вторых начитался про датчик влажности HDC2080, что не в коем случае, ни в чем, нельзя отмывать плату после пайки. Только безотмывочные флюсы и паяльные пасты. Поэтому наблюдаются остатки флюса на плате после отладки. Один проводок на обратной стороне - это косяк в разводке платы (косяк устранен). Второй был припаян на момент отладки без датчика DS18B20, так как ножки датчика служили соединителями дорожек между слоями, да так и был оставлен.

Корпус датчика нарисован в Компас 3D и распечатан на 3D принтере. До сих пор не придумаю как сделать нормальные защелки для соединения двух половинок корпуса, поэтому просто засверливаю с торцов и креплю маленькими шурупами.

Сверловка платы на CNC станке, программы для сверловки и фрезеровки сделаны в FlatCam из Gerber файлов сгенерированных Eagle. Фотошаблон напечатан на лазерном принтере, выдержан в парах ацетона 20 минут, после чего стал достаточно чёрным для изготовления печатной платы с помощью фоторезиста.

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

<a href="http://personeltest.ru/aways/github.com/Aleksei521/humidity-measure">Файлы вместе с исходниками на GitHub.</a>

Привет всем, хочу рассказать как добавить code coverage к angular/react проекту. В сети можно отыскать довольно много вариантов как это делать, и со своего опыта должен заметить что иногда с angular это не так просто. Рассмотрим как добавить code coverage к 11 версии angular (если у вас 7/8 этот пример может не работать, лучше обновится)

Angular

Установим всезависимости

npm i -D ngx-build-plusnpm i -D istanbul-instrumenter-loadernpm install -D @cypress/code-coverage

Переедемс protractor на cypress

ng add @briebug/cypress-schematic

Создадим файл cypress/coverage.webpack.js

module.exports = {  module: {    rules: [      {        test: /\.(js|ts)$/,        loader: 'istanbul-instrumenter-loader',        options: { esModules: true },        enforce: 'post',        include: require('path').join(__dirname, '..', 'src'),        exclude: [          /\.(e2e|spec)\.ts$/,          /node_modules/,          /(ngfactory|ngstyle)\.js/        ]      }    ]  }};

Обновим наш angular.jso

"serve": {  "builder": "ngx-build-plus:dev-server",  "options": {    "browserTarget": "angular-registration-login-example:build",    "extraWebpackConfig": "./cypress/coverage.webpack.js"  }},

Добавим к cypress/support/index.js

import '@cypress/code-coverage/support';

Добавим к cypress/plugins/index.js

module.exports = (on, config) => {  require('@cypress/code-coverage/task')(on, config)  // IMPORTANT to return the config object  // with the any changed environment variables  return config}

Запустим приложение, в console должна быть переменная window.__coverage__

После запуска приложения остается только запустить тесты npm run cy:open / cy:run

"cy:open": "cypress open","cy:run": "cypress run",

Как только тесты пройдут в корне приложения будет создана папка coverage

Посмотреть результат можно открыв файл coverage/lcov-report/index.html

Кликая по компонентам можно посмотреть какой код выполнялся и сколько раз, а какой еще не покрыт тестами

Сампроектможно скачать тут: https://github.com/NikolayKozub/angular-coverage-cypress

React

Установим все зависимости

npm i -D nycbabel-plugin-istanbulistanbul-lib-coverage@cypress/code-coverage@cypress/instrument-cra

Добавим к cypress/plugins/index.js

module.exports = (on, config) => {  require('@cypress/code-coverage/task')(on, config)    return config}

Добавим к cypress/support/index.js

import '@cypress/code-coverage/support'

Добавим скрипты к package.json

"start": "react-scripts start","start:coverage": "react-scripts -r @cypress/instrument-cra start",

Добавим .babelrc в корень проекта

{  "plugins": ["istanbul"]}

Запускаем тесты и смотрим отчет

Еще больше можно почитать тут

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

Вот вам вопрос на миллион долларов: является ли Cypress чем-то большим, чем платформа для автоматизации веб-тестов и может ли он заменить Selenium?

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

Краткое описание

Cypress - это тестовая веб-платформа нового поколения. Она была разработана на основе Mocha и Chai и представляет собой платформу для сквозного тестирования на основе JavaScript.

Selenium - это платформа для тестирования с открытым исходным кодом, используемая для автоматизации веб-браузера. Selenium WebDriver управляет браузером локально или удаленно и используется для проверки автоматизации пользовательского интерфейса. Другие элементы Selenium часто играют особую роль в отношении надежности и прочности продукта.

Архитектура

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

В Selenium, когда мы запускаем сценарий автоматизации Selenium, клиентская библиотека Selenium взаимодействует с Selenium API, который отправляет команду привязки драйверу браузера с помощью проводного протокола JSON. Драйвер браузера использует реестр HTTP для фильтрации всех команд управления HTTP-запроса и HTTP-сервера. Затем команды браузера выполняются в скрипте selenium, а HTTP-сервер отвечает скрипту автоматизированного тестирования.

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

Установка

В Cypress нет никакой предварительной настройки, просто установите файл.exe и автоматически настройте все драйверы и зависимости. Автоматизация может быть выполнена за считанные минуты. Одной из философий дизайна Cypress было сделать весь процесс тестирования удобным и комфортным для разработчиков, упаковки и объединения.

Чтобы использовать Selenium в проекте автоматизации, необходимо установить библиотеки линковки языков для использования предпочитаемого языка. Кроме того, в отношении браузеров, для которых вы хотите автоматически проводить проверки, вам понадобятся двоичные файлы для WebDriver.

Если мы также примем во внимание время и сложность имплементации, здесь Cypress имеет преимущество над Selenium.

Поддерживаемые языки

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

Selenium, в свою очередь, поддерживает широкий спектр языков Java, C#, Python, Ruby, R, Dar, Objective-C, Haskell и PHP, а также JavaScript.

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

Кросс-браузерная поддержка

Cypress поддерживает Canary, Chrome, Chromium, Edge, Edge Beta, Edge Canary, Edge Dev, Electron, Firefox (бета-поддержка), Firefox Developer Edition (бета-поддержка), Firefox Nightly (бета-поддержка).

Selenium поддерживает почти все основные браузеры на рынке, что является дополнительным преимуществом Selenium. Ниже приведен список поддерживаемых браузеров: Chrome (все версии), Firefox (54 и новее), Internet Explorer (6 и новее), Opera (10.5 и новее), Safari (10 и новее).

Selenium имеет более качественную кросс-браузерную поддержку по сравнению с Cypress, потому что Selenium обеспечивает поддержку почти всех доступных на рынке браузеров, в то время как в Cypress вы не можете проводить тестирования на Safari.

Параллельное исполнение пакета автоматизированного тестирования

По сравнению с Selenium в параллельной проверке, cypress отстает.

Selenium имеет много вариантов для параллельного исполнения, что для автоматизации тестирования очень важно. Grid широко используется в сообществе QA с TestNG для параллельного исполнения. А контейнеризация Docker может быть быстро интегрирована.

Производительность

Так как у Cypress нет нескольких архитектурных слоев, в отличие, например, от Selenium, он работает в браузере аналогичным образом. Именно поэтому мы наблюдаем его значительное преимущество над Selenium в скорости выполнения тестов.

Selenium имеет несколько уровней кода между тестом и браузером, в чем, например, Cypress проигрывает.

Интеграция процессов автоматизации с CI/CD

Cypress: Возможна, но ограничена. Существует только одна альтернатива для командной строки и библиотеки npm - Mocha. Служба CI должна поддерживать npm, а запись тестов для большинства записей на сервере CI будет платной.

Selenium: Возможно применение CI/CD. Любая библиотека тестов, их запись и шаблоны исполнения могут использоваться и быстро адаптироваться к требованиям.

Лицензирование

Cypress также доступен под лицензией MIT как open-source. Однако, если сравнивать его с Selenium, все функции Cypress не будут бесплатными, например, приборная панель Cypress бесплатна для seed и платна для Sprout, Tree и Forest. (https://www.cypress.io)

Selenium разрешен под лицензией Apache 2.0, правообладатель Software Freedom Conservation.

Поддержка ОС

Cypress: Windows, Mac, Linux

Selenium: Windows, Linux, Mac, Android, iOS

Поддержка BDD и DataDrivenTesting

Selenium поддерживает BDD и data-driven с помощью внешних библиотек, что в Cypress невозможно.

Локаторы для идентификации объектов

Cypress поддерживает только CSS и Xpath.

Cypress поддерживает все виды веб-локаторов, такие как ID, Name, XPath, селекторы CSS, текстовые ссылки, текстовые частичные ссылки и т.д.

Отчет о выполнении

Selenium: Extent, Allure и любые другие дашборды могут быть реализованы в наборах автоматизации.

Cypress: Дашборд - это как раз Cypress.

Окончательный вердикт

Selenium больше ориентирован на специалистов по автоматизации тестирования, а Cypress - на разработчиков для повышения эффективности TDD. Selenium был представлен в 2004 году, поэтому у него больше поддержки экосистемы, чем у Cypress, который был разработан в 2015 году и продолжает расширяться. Когда мы используем Selenium, в браузере можно манипулировать несколькими различными опциями, такими как Cookies, Local Save, Screen, Sizes, Extensions, Cypress control line options, но опция сети может быть обработана только при использовании Cypress.

Однако, вот некоторые из преимуществ, о которых заявляет Cypress:

1. Программа будет делать скриншоты во время проведения экспериментов. Затем мы можем просмотреть каждый запрос в качестве разработчика теста на панели Test Runner, чтобы увидеть, что произошло на каждом этапе.

2. Для тестирования с помощью Cypress не требуется никакого ожидания или режима сна. Прежде чем продолжить, он немедленно ожидает команд и утверждений.

3. Подобно модульным тестовым ситуациям, "шпионы" Cypress могут подтверждать и проверять действия функций, ответы сервера или таймеры по времени. С помощью Cypress вы можете заглушить сетевой трафик и персонализировать вызовы API в соответствии с вашими потребностями.

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

В преддверии старта курса "Java QA Engineer. Professional" приглашаем всех желающих на бесплатный двухдневный интенсив, в рамках которого мы рассмотрим CI- и CD- процессы, изучим основные инструменты и ключевые понятия (Server, agents, jobs. Fail fast, Scheduling, WebHooks). Подробно познакомимся с программной системой Jenkins и научимся интегрировать ее с git и Docker.

Записаться на интенсив:

• Что таое CI/CD, обзор популярных серверов и практика в Jenkins. День 1

• Что таое CI/CD, обзор популярных серверов и практика в Jenkins. День 2