Как тестировать API прямо в IDE, или почему я больше не использую Postman

i_am_chasing_the_clouds2 часа назад

Как тестировать API прямо в IDE, или почему я больше не использую Postman

Уровень сложностиПростойВремя на прочтение9 минОхват и читатели3.1KБлог компании HaulmontПрограммирование*Kotlin*Текстовые редакторы и IDE*Тестирование веб-сервисов*ОбзорPostman используют миллионы разработчиков — и не зря. Удобный интерфейс, коллекции, окружения, командный доступ. О чём еще мечтать?

Но если вы большую часть дня проводите в IDE, у этого подхода есть один постоянный friction point: нужно переключаться. Открыть Postman, вспомнить, где нужный запрос, скопировать токен из консоли, вставить руками. Потом вернуться обратно. И так по кругу.

С Amplicode и OpenIDE такой проблемы нет — там есть Connekt, HTTP-клиент на Kotlin DSL, который доступен прямо в IDE. Про него уже немало сказано, даже ребята из Домклик его распробовали и рассказали, как используют. Эта статья — краткий возврат к тому, как и зачем были добавлены те или иные возможности.

Этот клиент позволяет, не переключаясь из среды разработки и сохраняя «кодовое» мышление, писать запросы и выполнять даже целые сценарии с маппингами, DTO и перекладыванием результатов — всё это с помощью Kotlin DSL. Основные возможности можно посмотреть в следующем видео:

Подход показал себя хорошо: как только осваиваешь основные ключевые методы, начинаешь писать всё необходимое для тестирования и выполнения запросов уже на автомате.

Но хотелось бы иметь возможность не проверять данные глазами, а выполнять проверки — как в тестах, автоматически. И сразу видеть все выполненные и упавшие запросы. Ведь можно запускать целиком все свои запросы или даже сценарии в рамках одного ConneKt-файла.

Об этом и о связанной предметной области сегодня и пойдёт речь.

Kotlin DSL

Итак, обо всём по порядку. Начнём с Kotlin DSL.

Kotlin DSL — это подход к написанию конфигураций, а также технической и бизнес-логики, при котором они описываются как декларативный, типобезопасный Kotlin-код, максимально приближенный по стилю к естественному «языку предметной области».

Для разработчика это означает работу не со строковыми ключами и структурами (как в JSON или XML), а с полноценными объектами, функциями и лямбдами с ресивером (Type.() -> Unit), где контекст задаётся через this.

DSL строится на extension-функциях, builder-паттерне и scoped-блоках (apply, with, run), что позволяет писать вложенные конструкции без лишнего шума. Такой формат даёт строгую типизацию, автодополнение и безопасный рефакторинг, а сам код выглядит как конфигурация: компактный, читаемый и иерархически структурированный.

По сути, разработчик создаёт и использует внутренний язык, который компилируется в обычный Kotlin, но воспринимается как декларативное описание системы.

В целом, DSL (domain-specific language) — это подход, при котором язык создаётся под конкретную задачу, будь то SQL, RegExp или, например, Gradle-скрипты .

Моя цель в этой статье — не показать все его возможности, а скорее дать общее представление и продемонстрировать, насколько он удобен.

Для первого знакомства с темой я предлагаю прочитать эти две статьи:

Основы DSL в KotlinАвтор статьи: Сергей Прощаев ( @sproshchaev ) Руководитель направления Java-разработки в FinTech Вве...habr.comKotlin DSL: Теория и ПрактикаSql, RegExp, Gradle — что их объединяет? Всё это примеры использования проблемно-ориентированных язы...habr.comДля тех, кто поленится открывать ссылки, я всё-таки приведу короткий пример.

class Server { var host: String = "localhost" var port: Int = 8080

private val routes = mutableListOf<String>()

fun routing(block: Routing.() -> Unit) {
val routing = Routing().apply(block)
routes.addAll(routing.build())
}

fun start() {
println("Server started at $host:$port")
routes.forEach(::println)
}
}class Routing {
private val routes = mutableListOf<String>()

fun get(path: String) { routes += "GET $path" }

fun post(path: String) { routes += "POST $path" }

fun build(): List<String> = routes
}Для DSL-функций сделаем отдельный файл, например ServerDsl.kt

fun server(block: Server.() -> Unit): Server =
Server().apply(block)Также вынесем в отдельный файл метод main.

fun main() { server { host = "127.0.0.1" port = 9090

routing {
get("/users")
post("/users")
}
}.start()
}Здесь Server и Routing выступают как модель предметной области, а функция server, вынесенная в отдельный DSL-файл, задаёт уже сам язык конфигурации. За счёт этого код выглядит не как набор служебных вызовов, а как декларативное описание сервера и его маршрутов с последующим вызовом.

На этом, думаю, достаточно — мы здесь не ради подробного разбора Kotlin DSL.

Connekt

Выглядит удобно, понятно и мощно, правда? Мы подумали так же, когда решали проблему работы с HTTP-клиентами.

Главная беда большинства HTTP-клиентов в том, что они заставляют переключать внимание и отвлекаться от среды разработки и самого инженерного процесса вокруг задачи, которую кодишь. Кроме того, часто от тебя ожидается, что ты «серьёзно» знаешь ещё какой-то язык и владеешь отдельным инструментарием, чтобы всё это связать воедино. При этом среда разработки никак не помогает понять, как работает внешний HTTP-клиент и связанный с ним код.

Иногда HTTP-клиенты встраиваются в IDE в виде плагинов. Но такие решения в большинстве случаев плохо подходят для реальной работы, особенно если речь идёт о многошаговых сценариях. Они просто принимают настройки и выводят результат в консоль.

Но наша работа устроена иначе. Нам нужен инструмент, который:

• живёт прямо в среде разработки,
• позволяет выполнять целые сценарии запросов,
• даёт возможность удобно перекладывать данные между запросами и ответами в объектном виде.Чёрт возьми, мы разработчики. Мы хотим писать код, тестировать код кодом и выполнять сценарии запросов без ручного копирования данных и без необходимости каждый раз поднимать отдельное «вспомогательное» приложение.

Так появился Connekt — HTTP-клиент от Amplicode, встроенный в OpenIDE и который вы можете установить отдельно в любую другую IDE на базе JetBrains. Гибкий, с огромным количеством возможностей: он позволяет работать с системами авторизации и аутентификации, сертификатами, перекладывать данные между запросами и выполнять полноценные тестовые сценарии. И самое главное — всё это уже внутри IDE. Достаточно просто положить файлы в директорию проекта, добавить плейсхолдеры — и ими сможет пользоваться вся команда. Он был крут. Как самурайский меч в фильме «Убить Билла». Ультимативный инструмент. Будь такой у крутого Сэма из одноимённой игры — можно было бы играть без мышки.

Самые простые запросы выглядят максимально понятно и тривиально:

Но есть возможность строить и сложные цепочки:

Полноценный сценарий для http-запросов в ConneKtНо главное — это «кодовый» HTTP-клиент, который позволяет пользоваться подсказками среды разработки, автодополнением и привычными конструкциями, не требуя знания отдельного языка.

Более того, учитывая то, что всё больше кода сейчас пишут именно агенты, а не люди, Connekt становится ещё более интересным инструментом. Skills заточенные под Connekt уже доступны на GitHub и их можно использовать с Claude Code, Codex, OpenCode и любым другим популярным агентом.Да, вы используете Kotlin DSL. И при этом вам вовсе не обязательно быть Kotlin-разработчиком или глубоко знать язык, хотя с некоторыми базовыми вещами познакомиться всё же придётся. Но не стоит относиться к этому настороженно: ничего сверхъестественного не потребуется. Все знания — типовые и во многом универсальные: похожие концепции есть в большинстве языков программирования. Здесь не нужны «семь пядей во лбу» — вы просто играете по понятным правилам.

И всё было отлично. Мы показали клиент широкой аудитории — и получили положительный отклик. Даже Роман Елизаров, автор coroutines в Kotlin, высоко оценил инструмент и отзывался о нём с большим энтузиазмом. Про это даже целое видео есть.

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

Поскольку наш HTTP-клиент изначально живёт в Java/Kotlin-ландшафте, вариантов было много, и мнения разделялись. Однако в одном мы сошлись: всё необходимое должно быть «из коробки». Пользователь не должен думать о том, как подключать те или иные библиотеки для проверок. Наша цель была — не отвлекать его от написания сценариев и не заставлять разбираться в сторонних инструментах и их особенностях.

Мы попробовали разные библиотеки. Даже Rest Assured — с его богатым инструментарием — но столкнулись с техническими нюансами, например с подстановкой служебных заголовков.

В какой-то момент стало понятно: нам не хватает «просто проверок ответов» — без лишней сложности, но с красивым и гибким API.

В итоге мы остановились на AssertJ и Kotlin Power Assert. О них и поговорим далее.

AssertJ

AssertJ — это библиотека для тестирования, которая делает проверки понятными и читаемыми. Вместо сухого assertEquals ты пишешь что-то вроде assertThat(user.age).isGreaterThan(18), и это буквально читается как фраза.

За счёт этого проверки становятся не просто проверками, а чем-то вроде документации — по ним сразу видно, что именно ты ожидаешь от кода. Главный плюс AssertJ — удобство и ясность. Библиотека умеет красиво проверять списки, строки, исключения и даже целые объекты без необходимости писать кучу ручных сравнений.

Если тест падает, ты получаешь нормальное, понятное сообщение: что ожидалось и что пришло на самом деле. В итоге меньше времени уходит на разбор, а сами тесты выглядят аккуратно и структурированно.

Однако этого не всегда достаточно. Мы всё-таки пишем в Kotlin-like стиле, где ценятся стильные-модные-молодежные смузи результаты проверок, в которых сразу видно, что именно и где не сошлось.

Результаты проверок при помощи AssertJНе могу не похвастать тем, что в нашем http-клиенте можно писать удобные проверки, которые выглядят клево.

Однако, возможно пользователю не хотелось бы тащить дополнительные импорты в скрипты своих http-запросов. А подключение AssertJ этого требует. Так что мы оставили этот вариант доступным, но предоставили возможность пользоваться сравнениями из стандартной Kotlin-библиотеки.

AssertJ в ConneKt и импорт методов

Kotlin Power Assert

Раз уж речь зашла про Kotlin и его стандартные средства сравнения, грех не использовать все удобства по максимуму. Тем более что это совсем несложно. При этом мы не ожидаем, что наш пользователь обязательно является Kotlin-разработчиком.

Kotlin Power Assert — это плагин, который делает обычные assert гораздо умнее и понятнее. Когда проверка падает, он не просто сообщает «false», а показывает, что именно внутри выражения пошло не так. Например, при сравнении значений он прямо в сообщении об ошибке выводит их реальные значения — и причина становится очевидной без дебага и лишних логов.

Это особенно удобно для простых проверок и формул, где важно быстро понять, какое условие не выполнилось. При этом Power Assert — не замена полноценным библиотекам вроде AssertJ, а скорее приятное дополнение, которое делает результаты сравнений более наглядными.

Проверки из стандартной Kotlin-библиотекиСогласитесь, это выглядит более кратко с точки зрения кода.

А еще это добавляет наглядности результатам проверок.

Результаты проверок с Kotlin Power AssertВот это уже прям красиво. В консоли буквально раскладывается по полочкам, что и где не сходится, а вынесение промежуточных значений в переменные добавляет коду аккуратности.

При этом можно задать собственное сообщение для падающей проверки, а сами скрипты — спокойно дебажить.

Как вам такое, любители Postman? Всё ещё копируете значения руками между запросами?

На самом деле все это шутки и ирония. У любого инструмента есть своя аудитория и безусловно Postman бывает хорош в ситуациях, когда у тебя под рукой нет среды разработки.Но это ещё не всё. Я могу сразу получать DTO, выстраивать цепочки запросов и затем выполнять проверки. И даже при работе с объектами вывод остаётся наглядным и понятным.

Всем этим могуществом можно пользоваться уже сейчас. А главное, это бесплатно. Connekt доступен в бесплатной версии Amplicode.

Еще немного о Connekt и о грядущем

Однако мы пошли дальше и решили, что классно было бы проверять целые сценарии так, чтобы это было удобно. Далее я показываю возможности, которые еще недоступны на момент выхода статьи и станут доступны в грядущем релизе. Если вы хотите попробовать их уже сейчас, то напишите мне в личку :)

Проверки в Kotlin Power Assert для сценария.В такие моменты видна вся красота Kotlin Power Assert. Он отлично работает для точечных проверок, когда важно понять, что именно пошло не так внутри конкретного выражения. Но в реальных сценариях этого часто недостаточно: хочется выполнить сразу несколько проверок, увидеть результат по всем из них сразу, а не падать при первой же проблеме сверки. Здесь на помощь приходят soft assertions — подход, при котором проверки накапливаются и выполняются вместе, формируя итоговый отчёт со всеми несоответствиями. Это даёт сильный эффект: вы получаете и наглядную детализацию каждой проверки, и полный контроль над сценарием целиком.

Soft AssertionsВсе гениальное просто! Сейчас в моем сценарии два запроса и две проверки. А может быть 10 и я всегда увижу все результаты.

Но, у Kotlin Power Assert есть еще несколько клевых методов в API. Мы провели массу тестов и проверок для выявления сценариев, в которых пользуются Http-клиентами и это позволило нам подумать о читаемости кода и поддержать те, которые оказались уместны в рамках Http-клиента.

Методы require и checkТак вместе с soft assertions в Connekt появились require и check. Мне кажется, все это дает огромный прирост надежности в борьбе с багами и проверках API. Ведь, это почти полноценные тесты. Представляете какая возможность автоматизации тестирования появляется, если добавить такие скрипты к автотестам для вашего тестового окружения! - Закачаешься! А ведь все эти вещи не надо писать руками. Amplicode умеет генерировать их для ваших Rest-контроллеров. Пара кликов и целая стена тестовых сценариев, позволяющая провалидировать написанный код и защитить его от багов. Пушка!

Я бы с удовольствием «блеснул шпагой» и показал ещё несколько классных трюков с использованием Connekt, которые появятся в ближайшем будущем, но цель этой статьи — продемонстрировать именно проверки и их силу, поэтому остальное оставлю на десерт.

Заключение

Для полноценной среды разработки необыкновенно важно иметь свой полноценный http-клиент. В разных IDE представлены разные варианты, мы в OpenIDE пользуемся Connekt. На мой взгляд - это лучший из имеющихся http-клиентов и точно самый функциональный и гибкий. Он позволяет не переключаться из среды разработки и не обрывать нить мышления. Про Connekt можно разговаривать много, но лучше один раз попробовать, чем 100 раз увидеть. Пользуйтесь удобным, модным и молодежным тулингом. А еще присылайте нам свои интересные кейсы и спользования. На этом у меня все. Благодарю за внимание.

Актуальные новости о продукте проще всего получать, подписавшись на наш телеграм канал. Получить актуальную версию Amplicode можно на нашем сайте.Теги:• java
• spring
• openide
• http-клиент
• тестирование
• rest
• http
• kotlin
• автотесты
• qaХабы:• Блог компании Haulmont
• Программирование
• Kotlin
• Текстовые редакторы и IDE
• Тестирование веб-сервисов