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