PERF_CRON_HOUR_X - мое любимое 😍 каждый раз как первый раз

@avokhmianin Леша, мы починим это у себя в продукте в ближайшем спринте, может быть даже до релиза 😊

Олег, а эта фигня у вас по прежнему в 5:21 случается?

со Старым Новым Годом!

@dperevalov Дима, какая фигня?

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

@dperevalov я думаю сейчас это X стало рандомным (если их не стало несколько,  подсчет статистики, бекапы, установка апдейтов, которые тоже рандомные)

любопытный подход

Многие знакомы с таким неприятным явлением как «моргающие» или flaky тесты. Эти тесты один раз проходят успешно, а второй раз могут упасть на одном из шагов. Самым неприятным является то, что при отладке и попытке найти проблему они снова могут отлично проходить. В результате, на них тратится много времени и часто команда разработки начинает видеть красные билды на CI без особой причины.

Рекомендуемым поведением по отношению к flaky тестам является изоляция в карантин с последующим разбирательством. Но это не всегда хорошая стратегия. Для модульных и интеграционных тестов она ещё неплохо сработает, а вот для крупных e2e или системных тестов один такой тестовый сценарий может покрывать целый длинный бизнес флоу и без него в системе появится отличная лазейка для дефектов.

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

#тестирование #testing

Имхо, перезапуск флаки тестов порочная практика.

В целях диагностики причин норм, но чтобы билд позеленел решение так себе.

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

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

О, Костя)

Народ, а кто знает, когда где митапы будут? Чот давно никуда не ходила

Коллеги, привет. Разрешите немного похантить)

Ищем тестировщика с минимальным опытом. Компания AT Consulting.

Задачи:
   - Проводить ручное тестирование;
   - Регистрировать ошибки в баг-трекинговой системе, проверять исправления;
   - Проводить кроссбраузерное и кроссплатформенное тестирование;
   - Активно общаться с разработчиками, определять баг или все же фича ;)

Что ожидаем от кандидата:
   - Высшее техническое образование;
   - Знание основных видов и методов тестирования и умение их применять на практике;
   - Обязателен опыт в ручном тестировании веб-приложений;
   - Опыт разработки тестовой документации (тест-кейсы, чек-листы);
   - Желание развиваться в тестировании;
   - Умение конструктивно доносить свою точку зрения до собеседника.

Сам я не hr, а один из тестировщиков. Пишите вопросы в лс.

Пока пусто: (

Можем сделать, наверное?