если да то его вроде можно сконвертить в istanbul а потом через nyc в lcov. lcov сонар должен уметь понимать

ну оно в json генерит, а sonar xml хочет на вход 🙂 вот да, тоже в сторону истанбул смотрел

да одинаково должно быть что в этом проекте что в новом если настоите конфиги правильно и пакеты все поставите что нужно

👍

ага, по ходу то что нужно, спасибо 🙂 буду попробовать, вот еще нашлось:
https://stackoverflow.com/a/56759821/7414933

Бля, а стикеры и мерч?

Мы может скоро сделаем стикеры для чата )

Вот это я удачно зашёл

https://github.com/webdriverio/webdriverio/discussions/6212


Wdio готовится к новому релизу и собирает фидбеки по сайту

Завтра пройдет митап по запуску cypress на github actions.

Детали по ссылке:

https://twitter.com/bahmutov/status/1337031351598510082?s=19

а нет случайно чатика типа “вакансии js тестирования” а то мне ща прилетело интересное предложение (не знаю как по деньгам, но задачи вроде интересные” и я думаю кому бы это все скинуть кто мб работу ищет

https://t.me/qa_jobs
такой есть, но там строгие правила оформления.
я думаю, что если тут опубликуете, то тоже никто не обидится

случайно не в питере?

А чего это плагины, если не секрет?)

Поучительный рассказ Slack о том, как они Cypress используют

Прочитал замечательную историю о том, как развивался набор e2e-тестов для Slack. Они начали с небольшого набора тестов, созданных при помощи инструмента Cypress на внутреннем хакатоне, но по мере роста количества и сложности тестов начали возникать проблемы стабильности (flaky-тесты) и поддерживаемости (сложный анализ сбоев).

Что они сделали? Обмазали Cypress дополнительным слоем абстракции, который сделал тесты более понятными, а также позволил реализовать (невидимые для тестов) дополнительные проверки или ожидания, повышающие стабильность.

Правила, которые они выработали при создании этого слоя абстракции, достаточно хороши, чтобы использовать их в других проектах, независимо от того, что именно вы прячете под слоем абстракции — Cypress или Puppeteer или WebDriver:

* Selecting Elements: Instead of relying on product-driven class names or element ids, we add a custom “data-qa” attribute to elements that we need to select for testing purposes. This allows us to provide context for our selectors so they aren’t impacted by JS/CSS changes.

* Only create new components when needed. We shouldn’t try to define every UI Action possible, but define those that are being used by our test.

* Methods within a component should only modify the piece of UI that they’re written for. The component for the channel sidebar shouldn’t interact with the message input, for instance.

* Try to only break items into components where it makes sense rather than creating a lot of smaller components.

* The UI Abstraction is stateless. The test should maintain the state and validate against it.

https://slack.engineering/scaling-end-to-end-user-interface-tests/

удаленка

Основными задачами специалиста будет разработка системы для E2E тестирования, UI/API/integration/etc.
Система написана на Node.js/React с использованием TypeScript / GraphQL (Apollo). Контроль качества осуществляется в основном за счет автоматизации тестирования — в системе существует большое количество тестов, от API / до UI, E2E (Cypress) иинтеграции. Ищут человека, который будет разрабатывать / поддерживать этитесты. Кандидат должен обладать навыками JS-разработчика и иметь опыт в TDD.

вот контакт если что @aandrewegorov

Жметера)

Какой-то греческий бог, походу