Spock и JUnit с генерацией вряд ли помогут, они всё же не для этого. Я сама не использовала какие-либо инструменты для генерации, поэтому не могу подсказать что-то конкретное, но в целом доступные варианты можно посмотреть, например, здесь.
В то время, когда я работала с тестами с использованием Spock, JUnit не предоставлял возможности делать тесты параметризованными, что лично я находила максимально неудобным. Spock напротив давал эту возможность, не говоря уже об интуитивно понятном разделении на секции внутри теста, что улучшает его читаемость. Ну и немаловажный фактор – на проекте, который к слову был самым первым в моём опыте, уже были примеры того, как это должно выглядеть и работать, что значительно облегчало мне задачу в тот момент) Тут ничего решать особо было не нужно, я просто продолжила работать в заданном направлении.
Тем не менее в тех случаях, когда количество параметров становилось очень велико или же росло количество тестовых сценариев в рамках одного теста (а иногда и всё сразу), то тест превращался в длинную простынку кода, что выглядело откровенно говоря так себе.
С приходом JUnit5 проблема с дублированием кода для разных сценариев отпала. Плюс JUnit5 предложил, на мой взгляд, удобный способ имплементации параметров посредством отдельных файлов (именно этот вариант я рассмотрела в статье), что позволило не нагружать лишним объемом информации сам текст тестового метода и отделить тестовые сценарии от кодовой составляющей.
В добавок, хотя, синтаксис Groovy во многом похож на Java, которая является основным языком на нашем проекте, мне бы не хотелось создавать дискомфорт для своих коллег, которые не знакомы с Groovy, но которым придется работать с этим кодом.
Безусловно у Spock есть свои преимущества над JUnit в некоторых аспектах, как и наоборот, но в моем случае JUnit выглядел как более приемлемый выбор.
Spock и JUnit с генерацией вряд ли помогут, они всё же не для этого. Я сама не использовала какие-либо инструменты для генерации, поэтому не могу подсказать что-то конкретное, но в целом доступные варианты можно посмотреть, например, здесь.
Спасибо за вопрос.
В то время, когда я работала с тестами с использованием Spock, JUnit не предоставлял возможности делать тесты параметризованными, что лично я находила максимально неудобным. Spock напротив давал эту возможность, не говоря уже об интуитивно понятном разделении на секции внутри теста, что улучшает его читаемость. Ну и немаловажный фактор – на проекте, который к слову был самым первым в моём опыте, уже были примеры того, как это должно выглядеть и работать, что значительно облегчало мне задачу в тот момент) Тут ничего решать особо было не нужно, я просто продолжила работать в заданном направлении.
Тем не менее в тех случаях, когда количество параметров становилось очень велико или же росло количество тестовых сценариев в рамках одного теста (а иногда и всё сразу), то тест превращался в длинную простынку кода, что выглядело откровенно говоря так себе.
С приходом JUnit5 проблема с дублированием кода для разных сценариев отпала. Плюс JUnit5 предложил, на мой взгляд, удобный способ имплементации параметров посредством отдельных файлов (именно этот вариант я рассмотрела в статье), что позволило не нагружать лишним объемом информации сам текст тестового метода и отделить тестовые сценарии от кодовой составляющей.
В добавок, хотя, синтаксис Groovy во многом похож на Java, которая является основным языком на нашем проекте, мне бы не хотелось создавать дискомфорт для своих коллег, которые не знакомы с Groovy, но которым придется работать с этим кодом.
Безусловно у Spock есть свои преимущества над JUnit в некоторых аспектах, как и наоборот, но в моем случае JUnit выглядел как более приемлемый выбор.
Благодарю) Надеюсь, в какой-то мере была ещё и полезной)