IL
В начале звука на заставке не было
Size: a a a
2020 July 11
VB
В начале звука на заставке не было
ооооо!!! это мой промах.. спасибо, что сказал!
2020 July 14
VB
кстати, в одном из выпусков с Артемом говорили про Core Web Vitals. Не могу не поделиться хорошим видео, где объясняют что это такое с примером
https://www.youtube.com/watch?v=t8YBZLjL-KU
https://www.youtube.com/watch?v=t8YBZLjL-KU
АР
кстати, в одном из выпусков с Артемом говорили про Core Web Vitals. Не могу не поделиться хорошим видео, где объясняют что это такое с примером
https://www.youtube.com/watch?v=t8YBZLjL-KU
https://www.youtube.com/watch?v=t8YBZLjL-KU
Вот только недавно брался пересмотреть.
Когда новости обозревали, говорили
Только не помню, то ли сравнение testng и junit , то ли docker
Когда новости обозревали, говорили
Только не помню, то ли сравнение testng и junit , то ли docker
2020 July 16
D
Всем привет! Ребята возник вопрос. Когда нужно начинать параллелить тесты? От какого их количества? или по другим причинам?
AV
Всем привет! Ребята возник вопрос. Когда нужно начинать параллелить тесты? От какого их количества? или по другим причинам?
имхо, когда время их выполнения превышает ваши ожидания
D
Тоесть если ожиданий нет, то и не нужно. Верно я понимаю?
J🎩
Тоесть если ожиданий нет, то и не нужно. Верно я понимаю?
Ну если тебя устраивает скорость фидбэка, то да, не нужно
AZ
Тоесть если ожиданий нет, то и не нужно. Верно я понимаю?
нужно сразу рассчитывать под параллель. Т.к. сейчас 5 тестов, завтра будет 150. А у тебя ошибки изначально во фреймворке(статики много, например) и тебе теперь переписывать что-то нужно, что-то думать о чём-то, а как сделать так. чтобы они нормально ходили. И не всегда это возможно, к сожалению. А сразу бы заложил(потратил пять минут своего времени) и всё было бы хорошо. и пока их пять - то они последовательны, а когда их стало 150, преключил на пареллель
T
Полагаю, что параллелить тесты желательно тогда, когда будет подготовлен кластер для изолированного исполнения тестов, иначе может быть конфликт за фокус или данные (бывает такое). Если в планах - встраивание процесса автотестирования в CICD, то имхо это обязательно нужно делать. Причем чем раньше, тем лучше, иначе затем можно долго искать и исправлять конфликты параллельности
Но если тесты идут несколько секунд, то можно обойтись в принципе
Но если тесты идут несколько секунд, то можно обойтись в принципе
IR
нужно сразу рассчитывать под параллель. Т.к. сейчас 5 тестов, завтра будет 150. А у тебя ошибки изначально во фреймворке(статики много, например) и тебе теперь переписывать что-то нужно, что-то думать о чём-то, а как сделать так. чтобы они нормально ходили. И не всегда это возможно, к сожалению. А сразу бы заложил(потратил пять минут своего времени) и всё было бы хорошо. и пока их пять - то они последовательны, а когда их стало 150, преключил на пареллель
написание тестов параллельными может занять не 5 минут, а гораздо больше. Зависит от того, что параллелит. А то придется еще и потокобезопасный код писать учиться...
TL
Если тестов так мало что выполняются за несколько секунд, то либо их просто мало и они бесполезны, либо особо нечего тестировать
AZ
Inna Red
написание тестов параллельными может занять не 5 минут, а гораздо больше. Зависит от того, что параллелит. А то придется еще и потокобезопасный код писать учиться...
Да, я перегнул. даже меньше. Ну А если человек не умеет, значит самое время учиться.
AZ
А вообще, это всё условности.
основная мысль не в пяти минутах. а в том, что лучше сразу закладывать эту возможность.
основная мысль не в пяти минутах. а в том, что лучше сразу закладывать эту возможность.
IR
Тоесть если ожиданий нет, то и не нужно. Верно я понимаю?
а можешь рассказать немного условий, когда ожиданий нет? Интересно стало, как так, обычно вопрос времени встает
T
Если тестов так мало что выполняются за несколько секунд, то либо их просто мало и они бесполезны, либо особо нечего тестировать
На heisenbug был доклад "Автотесты: такие же, но лучше — Игорь Хрол", 10000 тестов за 1.8сек) Там конечно большие условности, но общая картина ясна
TL
Inna Red
а можешь рассказать немного условий, когда ожиданий нет? Интересно стало, как так, обычно вопрос времени встает
Видимо тогда когда тесты запускаются не на регулярной основе)
TL
На heisenbug был доклад "Автотесты: такие же, но лучше — Игорь Хрол", 10000 тестов за 1.8сек) Там конечно большие условности, но общая картина ясна
Да понятное дело что тесты бывают разные, но если тесты пишутся не на какую-то библиотеку, то в реальной жизни тесты работают дольше, интеграционные же тесты никто не отменяет
TL
А в вакууме всякое бывает, у меня сейчас к примеру есть порядка 37000 тестов выполняющихся меньше чем за секунду. Проверяю правильность работы скрипта миграции сравнивая 2 колонки в базе=) сама миграция больше часа при этом идет
r
Про контрактное тестирование упомянули, тоже интересно было бы послушать)
на прошедшем в этом году Selenium Camp было несколько докладов по теме. и они все в публичном доступе.