REST Assured и TestSprite: выразительные проверки, ручное покрытие

Сначала вывод

• Выбирайте REST Assured, если вы команда на JVM и хотите, чтобы тесты API жили на том же языке, в той же сборке и в том же процессе ревью, что и сам сервис.

• Выбирайте TestSprite, если узкое место — это широта покрытия и четыре проблемы состояния, а не синтаксис проверок.

• Используйте оба, если у вас есть набор тестов на REST Assured, который люди поддерживают. Сохраните тесты, которые вы написали осознанно, и добавьте вокруг них сгенерированную широту.

Сравнение бок о бок

Где REST Assured — правильный выбор

• Тесты как часть кодовой базы. Тот же язык, то же ревью, та же сборка. Для части команд это принципиально, и это справедливая позиция.

• Сложные собственные проверки. Когда корректность требует настоящей логики, а не сравнения полей, полноценный язык — подходящий инструмент.

• Уже сделанные вложения в JVM. Общие фикстуры, доменные объекты и инструменты сборки, которые у вас уже есть.

Что остаётся вашей задачей

Сессии истекают, идентификаторы приходится передавать между вызовами, часть эндпоинтов нельзя вызвать раньше других, и каждый прогон оставляет после себя записи. У REST Assured нет мнения ни по одному из этих вопросов — для DSL это правильно и означает, что все четыре ложатся на вашу тестовую инфраструктуру.

Есть и проблема формы покрытия: написанный вручную набор покрывает то, что кто-то вспомнил, а в продакшене ломаются как раз те пути ошибок и граничные значения, которые никто не пишет в конце спринта. Четыре механизма описаны в документации по тестированию API.

Проблема графа фикстур, конкретно

Момент, когда набор тестов на REST Assured начинает стоить дороже, чем приносит, обычно виден не в самих тестах, а в фикстурах JUnit.

Тесту нужен заказ. Заказу нужны клиент и товар. Клиенту нужен аккаунт с определённым тарифом. В виде фикстур это небольшое дерево, и JUnit соберёт его без всяких возражений. Затем второму тесту нужен тот же клиент, но другой товар, а третьему — два клиента. Дерево превращается в граф, фикстуры начинают принимать параметры, а кода подготовки становится больше, чем самих проверок.

Ничего из этого не является проблемой языка, и ничего из этого не решается более удобным DSL. Это цена выражения графа зависимостей во фреймворке, модель которого — дерево, и именно её снимает специально созданный для этого слой.

Использование обоих

Оставьте REST Assured для случаев, которые вы задали осознанно, и для проверок, требующих настоящей логики. Пусть сгенерированное покрытие обеспечивает широту по всей поверхности. И то и другое запускается из одного пайплайна.

Если вы оцениваете инструменты, сломайте что-нибудь намеренно

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

Если пайплайн принадлежит другой команде, GitHub App — путь наименьшего сопротивления: это вебхук, он ничего не меняет в вашем репозитории и срабатывает, когда ваша сборка сообщает, что новая версия выкачена. Если вы хотите видеть проверку прямо в репозитории, для этого есть шаг GitHub Actions . Смотрите репозиторий CLI.

Что TestSprite берёт на себя на уровне всего набора тестов

Четыре проблемы, которые лежат за пределами любого DSL. Auto-Authentication для времени жизни сессии, Dynamic Variables для значений, захваченных между вызовами, Dependency Chains, чтобы порядок выводился, а не кодировался во вложенности фикстур, и Auto-Cleanup, привязанный к тому, что создал каждый прогон.

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

Что в итоге остаётся вашей JVM-команде: REST Assured для случаев, которые вы задали осознанно, и для проверок, требующих настоящей логики, — и никакого графа фикстур под ними, который надо поддерживать. И то и другое запускается из одного пайплайна.