Size: a a a

JavaScript testing

2020 November 20

SM

Sewa Makhinya in JavaScript testing
Oleksandr Khotemskyi
считай это как использование внешней библиотеки )
ну я всё равно не понимаю, почему не написать (более) простой метод и там это всё не разрулить
но выглядит круто, да
всё больше предвкушаю, как когда-нибудь вернусь в TS и попробую всё это
источник

OK

Oleksandr Khotemskyi in JavaScript testing
Sewa Makhinya
ну я всё равно не понимаю, почему не написать (более) простой метод и там это всё не разрулить
но выглядит круто, да
всё больше предвкушаю, как когда-нибудь вернусь в TS и попробую всё это
а на чем ты сейчас?
источник

SM

Sewa Makhinya in JavaScript testing
Oleksandr Khotemskyi
а на чем ты сейчас?
дык Java
источник

B

Bola in JavaScript testing
Oleksandr Khotemskyi
ох, я не уверен если честно
мозгодробительно
источник

m

mkots in JavaScript testing
Oleksandr Khotemskyi
а дай селектор
источник

m

mkots in JavaScript testing
Вот такая срань я имел ввиду, я обожаю такое писать
источник

OK

Oleksandr Khotemskyi in JavaScript testing
mkots
Вот такая срань я имел ввиду, я обожаю такое писать
источник

OK

Oleksandr Khotemskyi in JavaScript testing
оно просто fallback в Element тип делает
источник

m

mkots in JavaScript testing
нуу, такое, можно конечно кастануть, но и без этого типизатора можно))
источник

OK

Oleksandr Khotemskyi in JavaScript testing
ну тут логично - мы ж не знаем что у тебя будет :not(p) - мож span, мож div мож button
источник

m

mkots in JavaScript testing
хотя да, откуда ему знать что за нот
источник

m

mkots in JavaScript testing
но классно в целом, прям настроение поднялось
источник

OP

Oleksandr Pelykh in JavaScript testing
ребята, привет
нужно мнение экспертов )

есть у меня мониторинговые тесты - ранятся на проде с определенной периодичностью (например, 5 минут) и проверяют работоспособность продукта

вопрос касательно инфрастуктуры тестов – обязательно ли, чтобы джоба (с тестами) завершалась с ошибкой, когда падает тест?

приведу несколько аргументов от себя
- конечно, в стандартном CI/CD процессе упавшая джоба и стоп пайплайна - это маст хев. но в данном случае (помним, что тесты мониторинговые) стоп пайплайна нам не нужен, нам нужно только оповещение что именно упало
- назревает вывод, что раз мы должны знать, что есть падение, то и джобу нужно завершать с еррором. но можно же ошибку слать руками в момент завершения всех тестов но еще, так сказать, не выходя из контейнера. а сам контейнер завершать успешно, тестовый прогон ведь был выполнен, хоть и тест упал
- возможно, у вас назреет еще один вопрос - почему я задаюсь этим вопросом, не пусть себе завершается джоба с эррором, ведь в ней упавший тест. но! как тогда нам различать падение джобы произошло из-за ошибок ифнрастуктуры (не поднялся контейнер, не хватило памяти и т.д.) или упал тест? ну.. можно через еррор коды, но имхо, это геморно. или нет?
- скорее, в CI/CD системах (Jenkins, Gitlab, Github) упавшие джобы хендлить удобно и легко настроить алерты. но мои ранятся в GCP. и здесь падение джобы рассматривается как что-то аномальное и это вызывает некие проблемы с конфигурацией алертов. (например, мы будем получать алерт, пока не удалим упавшую джобу, даже если после нее уже была успешная)

поделитесь вашим опытом. буду рад комментариям 💪
источник

NK

ID:0 in JavaScript testing
Воркшоп Cypress for 2020 с Димой Коваленко!

3 декабря пройдет воркшоп по Cypress.

📜 План занятия:
✔️ Рассмотрим, как совершенно новая архитектура Cypress меняет подход к тестированию и делает написание тестов быстрее и приятнее
✔️ В каком случае НЕ следует использовать Cypress
✔️ Обзор основных компонентов Cypress
✔️ Написание первых тестов, запуск и настройка
✔️ Запуск на CI и подключения сторонних сервисов

🎬 Online
📆 Дата: 3 Декабря
⏰ Начало с 19:30 до 22:00
🗣 Язык: русский
💵 Стоимость:
первые 5 билетов - 400 грн
все остальные по 470 грн (~16$)


Детали и билеты по ссылке:
https://fb.me/e/yjRgfOkQ
источник

OK

Oleksandr Khotemskyi in JavaScript testing
Oleksandr Pelykh
ребята, привет
нужно мнение экспертов )

есть у меня мониторинговые тесты - ранятся на проде с определенной периодичностью (например, 5 минут) и проверяют работоспособность продукта

вопрос касательно инфрастуктуры тестов – обязательно ли, чтобы джоба (с тестами) завершалась с ошибкой, когда падает тест?

приведу несколько аргументов от себя
- конечно, в стандартном CI/CD процессе упавшая джоба и стоп пайплайна - это маст хев. но в данном случае (помним, что тесты мониторинговые) стоп пайплайна нам не нужен, нам нужно только оповещение что именно упало
- назревает вывод, что раз мы должны знать, что есть падение, то и джобу нужно завершать с еррором. но можно же ошибку слать руками в момент завершения всех тестов но еще, так сказать, не выходя из контейнера. а сам контейнер завершать успешно, тестовый прогон ведь был выполнен, хоть и тест упал
- возможно, у вас назреет еще один вопрос - почему я задаюсь этим вопросом, не пусть себе завершается джоба с эррором, ведь в ней упавший тест. но! как тогда нам различать падение джобы произошло из-за ошибок ифнрастуктуры (не поднялся контейнер, не хватило памяти и т.д.) или упал тест? ну.. можно через еррор коды, но имхо, это геморно. или нет?
- скорее, в CI/CD системах (Jenkins, Gitlab, Github) упавшие джобы хендлить удобно и легко настроить алерты. но мои ранятся в GCP. и здесь падение джобы рассматривается как что-то аномальное и это вызывает некие проблемы с конфигурацией алертов. (например, мы будем получать алерт, пока не удалим упавшую джобу, даже если после нее уже была успешная)

поделитесь вашим опытом. буду рад комментариям 💪
если тесты мониторинговые - то они ведь куда-то репортят? И там собираются метрики - слать page или нет?
источник

OK

Oleksandr Khotemskyi in JavaScript testing
Oleksandr Khotemskyi
если тесты мониторинговые - то они ведь куда-то репортят? И там собираются метрики - слать page или нет?
в таком случае если решение - «все упало, надо будить людей» принимается не на ci/cd - то можно и не заваливать саму джобу, НО - если джоба будет всетаки упавшая в пайплайне - то это как-то наглядней будет ИМХО
источник

OP

Oleksandr Pelykh in JavaScript testing
Oleksandr Khotemskyi
если тесты мониторинговые - то они ведь куда-то репортят? И там собираются метрики - слать page или нет?
да, репортят

`слать page или нет?`
page? не понял
источник

OK

Oleksandr Khotemskyi in JavaScript testing
Oleksandr Pelykh
да, репортят

`слать page или нет?`
page? не понял
page - это пейджер ) типа дежурного будить )
источник

OP

Oleksandr Pelykh in JavaScript testing
понял тебя, спасибо
источник

AV

Alex Vershinin in JavaScript testing
Oleksandr Pelykh
ребята, привет
нужно мнение экспертов )

есть у меня мониторинговые тесты - ранятся на проде с определенной периодичностью (например, 5 минут) и проверяют работоспособность продукта

вопрос касательно инфрастуктуры тестов – обязательно ли, чтобы джоба (с тестами) завершалась с ошибкой, когда падает тест?

приведу несколько аргументов от себя
- конечно, в стандартном CI/CD процессе упавшая джоба и стоп пайплайна - это маст хев. но в данном случае (помним, что тесты мониторинговые) стоп пайплайна нам не нужен, нам нужно только оповещение что именно упало
- назревает вывод, что раз мы должны знать, что есть падение, то и джобу нужно завершать с еррором. но можно же ошибку слать руками в момент завершения всех тестов но еще, так сказать, не выходя из контейнера. а сам контейнер завершать успешно, тестовый прогон ведь был выполнен, хоть и тест упал
- возможно, у вас назреет еще один вопрос - почему я задаюсь этим вопросом, не пусть себе завершается джоба с эррором, ведь в ней упавший тест. но! как тогда нам различать падение джобы произошло из-за ошибок ифнрастуктуры (не поднялся контейнер, не хватило памяти и т.д.) или упал тест? ну.. можно через еррор коды, но имхо, это геморно. или нет?
- скорее, в CI/CD системах (Jenkins, Gitlab, Github) упавшие джобы хендлить удобно и легко настроить алерты. но мои ранятся в GCP. и здесь падение джобы рассматривается как что-то аномальное и это вызывает некие проблемы с конфигурацией алертов. (например, мы будем получать алерт, пока не удалим упавшую джобу, даже если после нее уже была успешная)

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

запускать постоянно тесты это немного странно, никогда такого не видел)
источник