Блеск и нищета фреймворков тестирования: используем Groovy для скриптинга end-to-end тестов

Условия странные, но они бывают.

Самое простое: может отсутствовать jdk (в наличии только jre).

Может отсутствовать доступ к репозиториями и соответственно придется настривать maven/gradle на использование локальных библиотек.

Кто-то может посчитать, mvn/gradle просто лишним слоем абстракции для запуска тестов. Для запуска с лихвой хватает junit-platform-console.

Сводится все в принципе к одному: по той или иной причине хочется scripting для описания тестов на "jvm compatible" языке.

"Устанавливать" groovy (как дистрибутив) не обязательно - можно например добавить пару библиотек в classpath и использовать custom test engine, как я показал в последнем примере.

Я бы понял, если бы это было в контексте однократной необходимости выполнить какие-то проверки, т.к., например, в тестовом окружении какой-то баг не воспроизводится, но использовать самопальные скрипты, вместо давно работающих проверенных инструментов, ну, скажем так, на любителя.

Так я об этом и писал) Вот оно:

"...Предположим, у нас уже есть тестовый сценарий, и мы хотим его слегка поменять, прогнать и посмотреть, что получится. Или вообще пишем первый сценарий и хотим поэкспериментировать... Немного vim или nano и код теста можно изменить прямо в консоли тестовой среды."

Это не условия странные, а прямо таки эталонная реализация принципа "Зачем просто, когда можно сложно?"

А в чем сложность? Я как раз хотел показать насколько просто использовать для тестирования код написанный на Groovy без его предварительной компиляции. А если еще и через junit console, так вообще красота.

Увы, условия какие есть - их не изменить. Буду очень признателен, если подскажите простое решение для прототипирования/экспериментов, кроме "автоматизировать процесс сборки, deploy'я и запуска кода еще не находящегося в scm".