Давайте еще чуть уточню условия из статьи: есть удаленный хост под управлением Linux. Взаимодействие с объектом тестирования возможно только с этого хоста, только при помощи java библиотек. На хосте нет ни maven, ни gradle. Нет доступа до интернета, репозиториев с артефактами и gradle distribution. Нельзя поднять proxy или ssh туннель до рабочей среды разработчика/тестировщика. Всё во имя безопасной безопасности. Есть только доступ по ssh, scp для копирования файлов и возможность запускать произвольные программы под JVM.
Я бы понял, если бы это было в контексте однократной необходимости выполнить какие-то проверки, т.к., например, в тестовом окружении какой-то баг не воспроизводится, но использовать самопальные скрипты, вместо давно работающих проверенных инструментов, ну, скажем так, на любителя.
Так я об этом и писал) Вот оно:
"...Предположим, у нас уже есть тестовый сценарий, и мы хотим его слегка поменять, прогнать и посмотреть, что получится. Или вообще пишем первый сценарий и хотим поэкспериментировать... Немного vim или nano и код теста можно изменить прямо в консоли тестовой среды."
Это не условия странные, а прямо таки эталонная реализация принципа "Зачем просто, когда можно сложно?"
А в чем сложность? Я как раз хотел показать насколько просто использовать для тестирования код написанный на Groovy без его предварительной компиляции. А если еще и через junit console, так вообще красота.
Увы, условия какие есть - их не изменить. Буду очень признателен, если подскажите простое решение для прототипирования/экспериментов, кроме "автоматизировать процесс сборки, deploy'я и запуска кода еще не находящегося в scm".
Самое простое: может отсутствовать jdk (в наличии только jre).
Может отсутствовать доступ к репозиториями и соответственно придется настривать maven/gradle на использование локальных библиотек.
Кто-то может посчитать, mvn/gradle просто лишним слоем абстракции для запуска тестов. Для запуска с лихвой хватает junit-platform-console.
Сводится все в принципе к одному: по той или иной причине хочется scripting для описания тестов на "jvm compatible" языке.
"Устанавливать" groovy (как дистрибутив) не обязательно - можно например добавить пару библиотек в classpath и использовать custom test engine, как я показал в последнем примере.
Давайте еще чуть уточню условия из статьи: есть удаленный хост под управлением Linux. Взаимодействие с объектом тестирования возможно только с этого хоста, только при помощи java библиотек. На хосте нет ни maven, ни gradle. Нет доступа до интернета, репозиториев с артефактами и gradle distribution. Нельзя поднять proxy или ssh туннель до рабочей среды разработчика/тестировщика. Всё во имя безопасной безопасности. Есть только доступ по ssh, scp для копирования файлов и возможность запускать произвольные программы под JVM.
Так я об этом и писал) Вот оно:
"...Предположим, у нас уже есть тестовый сценарий, и мы хотим его слегка поменять, прогнать и посмотреть, что получится. Или вообще пишем первый сценарий и хотим поэкспериментировать... Немного vim или nano и код теста можно изменить прямо в консоли тестовой среды."
А в чем сложность? Я как раз хотел показать насколько просто использовать для тестирования код написанный на Groovy без его предварительной компиляции. А если еще и через junit console, так вообще красота.
Увы, условия какие есть - их не изменить. Буду очень признателен, если подскажите простое решение для прототипирования/экспериментов, кроме "автоматизировать процесс сборки, deploy'я и запуска кода еще не находящегося в scm".
Условия странные, но они бывают.
Самое простое: может отсутствовать jdk (в наличии только jre).
Может отсутствовать доступ к репозиториями и соответственно придется настривать maven/gradle на использование локальных библиотек.
Кто-то может посчитать, mvn/gradle просто лишним слоем абстракции для запуска тестов. Для запуска с лихвой хватает junit-platform-console.
Сводится все в принципе к одному: по той или иной причине хочется scripting для описания тестов на "jvm compatible" языке.
"Устанавливать" groovy (как дистрибутив) не обязательно - можно например добавить пару библиотек в classpath и использовать custom test engine, как я показал в последнем примере.