Хорошая идея, у нас были похожие мысли, но мы не нашли способа задавать в Surefire + JUnit 5 порядок запуска тестов, только порядок запуска классов. Не подскажете как вы это делаете?
По факту так работают перезапуски во всех инструментах. Наши тесты атомарны и поэтому если возникают какие-то ошибки, то скорее всего они возникнут опять и на перезапуске, так как шаги повторяются те же самые. Основная задача перезапусков для нас — избавиться от падений тестов при временных неполадках инфраструктуры. К сожалению, приходится выбирать между кучей красных тестов и потенциально низкой возможностью пропустить плавающий баг. Если тест будет часто падать, то он будет автоматически выключен нашей системой по распознаванию нестабильных тестов и овнеры будут разбираться, это нестабильный тест или плавающий баг.
Не очень понял, что вы имеете ввиду. Насколько я знаю, Surefire по умолчанию использует одну JVM для всех тестов в одном модуле (ссылка). Можете пожалуйста объяснить, где происходит пересоздание JVM и какая именно особенность mvnd может помочь решить проблему?
Доброго времени суток, спасибо за вопрос. Есть несколько причин, почему запуск всех модулей в одной job в нашем случае лучше, чем запуски в отдельных jobs.
1. Для 250 модулей придется запускать 250 job, накладные расходы на поддерживание TeamCity агентов будет очень высоким.
2. Все команды работают над одним и тем же продуктом и часто запускают тесты друг друга. Изменение одного модуля иногда может влиять на 30 других модулей. Проще запустить все затронутые модули в одной сборке, чем запускать 30 сборок. (как мы вычисляем, какие модули были затронуты, можно прочитать здесь)
Если команды и их модули достаточно изолированы друг от друга ваше решение тоже хорошо подходит.
Хорошая идея, у нас были похожие мысли, но мы не нашли способа задавать в Surefire + JUnit 5 порядок запуска тестов, только порядок запуска классов. Не подскажете как вы это делаете?
По факту так работают перезапуски во всех инструментах. Наши тесты атомарны и поэтому если возникают какие-то ошибки, то скорее всего они возникнут опять и на перезапуске, так как шаги повторяются те же самые. Основная задача перезапусков для нас — избавиться от падений тестов при временных неполадках инфраструктуры. К сожалению, приходится выбирать между кучей красных тестов и потенциально низкой возможностью пропустить плавающий баг. Если тест будет часто падать, то он будет автоматически выключен нашей системой по распознаванию нестабильных тестов и овнеры будут разбираться, это нестабильный тест или плавающий баг.
Добрый день, спасибо за фидбек.
Не очень понял, что вы имеете ввиду. Насколько я знаю, Surefire по умолчанию использует одну JVM для всех тестов в одном модуле (ссылка). Можете пожалуйста объяснить, где происходит пересоздание JVM и какая именно особенность mvnd может помочь решить проблему?
Доброго времени суток, спасибо за вопрос.
Есть несколько причин, почему запуск всех модулей в одной job в нашем случае лучше, чем запуски в отдельных jobs.
1. Для 250 модулей придется запускать 250 job, накладные расходы на поддерживание TeamCity агентов будет очень высоким.
2. Все команды работают над одним и тем же продуктом и часто запускают тесты друг друга. Изменение одного модуля иногда может влиять на 30 других модулей. Проще запустить все затронутые модули в одной сборке, чем запускать 30 сборок. (как мы вычисляем, какие модули были затронуты, можно прочитать здесь)
Если команды и их модули достаточно изолированы друг от друга ваше решение тоже хорошо подходит.