В общем получилось с помощью библиотеки Fuel

fuel говно

Наверно да (долго разбирался), но работает

аргументированно высказана оценка

Такой код просто не мог бы пройти ревью. Реджект сразу.
https://github.com/kittinunf/Fuel/blob/7b56b22799905ea3c4b7b26addd84dc978983247/fuel/src/main/kotlin/com/github/kittinunf/fuel/core/FuelManager.kt#L32

но в итоге-то всё равно к пустой строке нуль приводят :)
https://github.com/kittinunf/Fuel/blob/7b56b22799905ea3c4b7b26addd84dc978983247/fuel/src/main/kotlin/com/github/kittinunf/fuel/core/Encoding.kt#L32

А глобальное изменяемое состояние остаётся.

И два разных кода, которые независимо мутируют baseUrl, уже не смогут сосуществовать.

так они этого и не скрывают - даже в README об этом написано. Это не косяк, а фича :)

Вообще всё равно, как это называть. На свалку такое.

Fuel больше подходит для быстрого прототипирования, когда надо написать скриптик минут за 5 например и не трогать его больше никогда
но даже тут, глобальное состояние это ппц конечно))

согласен. Но глобальное состояние удобно использовать в тестах на какой-то домен/путь - прописал один раз и погнал в каждом тесте только относительный путь указывать.
Альтернативой этому будет "правильный" подход, где в каждом тесте мы будем повторно прописывать один и тот же базовый путь, а то и вовсе, заведём некий сторонний класс или метод-обёртку, который будет это делать для тестового клиента.

Другой момент - использование библиотеки в качестве клиента в коде проекта, который должен ходить только на один базовый путь. И такой подход Fuel позволяет добавить защиту от случайного указания не относительного, а абсолютного URL, так как он будет всегда относительный. Но мы снова можем сказать, что так не правильно и надо везде явно заново указывать базовый путь и всё такое.

Короче, глобальное состояние это не плохо, если знаешь когда и зачем его применять. Или рельно тут все выступившие никогда не используют "глобальных" значений для каких-либо переменных из окружения ОС?

Глобальные состояния применимы только в одном случае - когда они статичные и неизменяемые. Во всех остальных случаях это увеличивает сложность дальнейшей поддержки системы
Не совсем понял про проблемы с указанием относительного\абсолютного урл т.к. у меня их никогда не было, ничего не могу сказать
По тестам, ты не должен напрямую вообще обращаться к урлам каким-то. У тебя все закрыто за интерфейсами типа fun getData(): Data и ты подменяешь уже их реализацию, которая просто возвращает моковые значения например. В других случаях, ты тестируешь сам веб-клиент (okhttp + retrofit, fuel и т.д) делая лишнюю работу и тестируя библиотеку вместо своего кода

про тесты имелось в виду, когда ты тестируешь свой rest-сервис например. После его поднятия у тебя будет единый адрес/базовый путь и только относительные пути до API-методов. При этом нельзя использовать пути из основного кода - тест API-метода будет нечестным

кстати, а  RestAssured тоже почти говно из-за этого?
https://github.com/rest-assured/rest-assured/blob/master/rest-assured/src/main/java/io/restassured/RestAssured.java#L361

Я работаю тестировщиком.
Работал с Apache HTTP Client, Rest-Assured и сейчас решил попробовать Retrofit.

Скажу так, у каждого свои плюсы и минусы.
Но для тестирования я бы выбрал и рекомендовал Rest-Assured!
Да, Retrofit "красивее" позволят писать эендпомнты. Для меня огромным минусом стало неудобство писать запросы в синхронном стиле. А для тестирования вы явное асинхронно писать не будете :)
Также у Retrofit дурацкая работа с ошибки в запросах.

Короче несмотря на мелкие неудобства Rest-Assured, я рекомендую его.

А Retrofit оставьте для разработки, для коей он и был сделан.

Для Base URL ты можешь использовать .spec в Rest-Assured, а ручки сунуть в Enum и будет тебе и счастье.

почему в ENUM, а не в интерфейс? или, раз уж Kotlin, просто глобальными переменными в тестовом модуле...

использование RequestSpecification по сути тоже самое, что и использование глобального basePath. Просто вы глобально объявите не одну строчку, а целый объект, который будете везде подсовывать. Или в каждом тесте(-suite) будете с нуля его создавать? Ну, это если утрированно.

ЗЫ: да я и так счастлив. Просто не хочу, чтобы продукт называли говном только из-за того, что не видят (не хотят видеть) области и особенности его применения

Ну все делать глобальным это стрёмно - можно увлечься и потом при попытке запуска тестов в параллели искать где накосячил :)

ENUM... Да просто первое что пришло в голову :)

Я считаю что без разницы что ты используешь, главное чтобы код выглядел читаемо и без говна в тестах.

Кстати, можешь глянуть на мой шаблон проекта на GitHub @romsper проект qa-base-project.
Надеюсь на днях я его обновлю и добавлю новых примеров и технологий :)

Омг, опять?

@whalemare, чёт у вас тут какая-то пробелма с рекламой