Комментарии 5
Тест будем считать прошедшим, если он прошел хотя бы один раз.
Интересная концепция. То есть, типа, юзер (скажем, в системе управления проектами) жмёт кнопку "добавить задачу", пишет описание, "сохранить" — бабах, какие-то стек трейсы, ошибки. Юзер матерится, нажимает "назад", пишет всё заново, "сохранить" — бабах, и т.д. Фича считается работающей, если в конце концов юзеру удалось хотя бы один раз создать задачу?
По факту так работают перезапуски во всех инструментах. Наши тесты атомарны и поэтому если возникают какие-то ошибки, то скорее всего они возникнут опять и на перезапуске, так как шаги повторяются те же самые. Основная задача перезапусков для нас — избавиться от падений тестов при временных неполадках инфраструктуры. К сожалению, приходится выбирать между кучей красных тестов и потенциально низкой возможностью пропустить плавающий баг. Если тест будет часто падать, то он будет автоматически выключен нашей системой по распознаванию нестабильных тестов и овнеры будут разбираться, это нестабильный тест или плавающий баг.
Интересно, как раз обсуждали с вашим коллегой в предыдущем посте проблему длинных хвостов, но у нас я пока решил ее другим путем: беру статистику продолжительности тестов, все тесты дольше минуты перемещаю в рандомное место в первой 1/N-й части очереди, а при ретрае — вместо конца — тоже в 1/N-ю от оставшейся очереди (у нас свой раннер, так что можем управлять очередью, как хотим), в итоге даже длинные выбросы по времени равномерно замазываются кучей коротких тестов (в нашем случае немедленный ретрай мы не хотим, чтобы не ддосить, вероятно, и без того нагруженный сейчас сервис, из-за долгого ответа/ошибки которого тест, скорее всего, и упал).
Хорошая идея, у нас были похожие мысли, но мы не нашли способа задавать в Surefire + JUnit 5 порядок запуска тестов, только порядок запуска классов. Не подскажете как вы это делаете?
У нас свой java-фреймворк (поверх Selenoid + TestNG), в котором мы запускаем тесты программно (programmatically), т.е. не через мавен и плагины, соответственно и очередь на запуск формируем сами, и управляем ей на свое усмотрение.
(возможно, про это в скором будущем будет статья, есть еще старый доклад на testconf, от него сохранилась только презентация, но она довольно информативная).
Как перезапускать упавшие тесты параллельно