REST Assured 6.0.0 работает уже на Java 17+, но это не самая неприятная новость для команд, которые гоняют автотесты на API. Куда хуже другое: зелёный прогон легко маскирует сломанный контракт API, если тесты проверяют только статус-код и пару полей. Для русскоязычных разработчиков это история не про теорию, а про привычный сценарий, когда баг прилетает не из CI, а из мобилки или фронта после релиза.
Об этом пишет Habr / Карьера в разборе Сергея Прощаева, Tech Lead и руководителя направления Java | Kotlin-разработки в FinTech & E-commerce, который также преподаёт в OTUS. Исходный тезис у автора простой и неприятный: многие тесты API на деле проверяют не контракт API, а собственное спокойствие. Пока сервис отвечает с кодом 200, тело не пустое, а пара ожидаемых значений на месте, пайплайн выглядит здоровым. Но если бэкенд тихо переименовал поле, сменил тип значения или убрал часть структуры, такой тест часто остаётся зелёным.
В качестве базового антипримера автор берёт типичный тест на REST Assured: запрос к эндпоинту заказа, проверка кода 200, поля id и наличия totalPrice. Проблема в том, что такой набор ассертов не видит структуру ответа целиком. Если внутри массива товаров поле price внезапно стало unitPrice, если totalPrice из числа превратился в строку или если часть обязательных атрибутов просто исчезла, тест может не заметить подмену. А вот клиентское приложение заметит быстро, обычно в самый неудобный момент.
Решение, которое предлагает Прощаев, выглядит вполне приземлённо: вынести ожидаемую структуру ответа в JSON Schema и валидировать по ней ответ одной проверкой через модуль json-schema-validator для REST Assured. В примере используется условный сервис заказов с эндпоинтом GET /api/v1/orders/{id}. Схема описывает обязательные поля заказа, типы значений, допустимые статусы и структуру массива items, где у каждой позиции должны быть sku, price и quantity. В теории это закрывает главную дыру: если обязательное поле пропало или поменяло тип, тест падает не после жалобы пользователя, а на прогоне.
Но на этом месте начинается более интересная часть, ради которой заметку и стоит читать. Автор отдельно акцентирует, что сама по себе схема ещё не гарантирует жёсткую проверку. Если ограничиться перечислением properties и required, можно по-прежнему пропустить лишние поля и часть нежелательных изменений. Поэтому схему приходится делать строгой: явно описывать обязательные атрибуты, следить за типами, ограничивать допустимые значения через enum и не оставлять структуру «на авось». Иначе контракт API формально описан, но практической пользы от него немного.
Есть и чисто инженерный слой, который знаком почти любой Java-команде: зависимости умеют ломать тесты не хуже багов в продукте. Прощаев фиксирует окружение на июнь 2026 года: Java 17+, REST Assured 6.0.0, JUnit 5 и Maven. По его словам, REST Assured 6.0.0 вышел 12 декабря 2025 года, поднял минимальную планку до Java 17, перешёл на Groovy 5 и добавил поддержку Spring 7 и Jackson 3. Отдельно он предупреждает о конфликте с Hamcrest: библиотека подтягивается транзитивно, а несовместимая версия может привести к NoSuchMethodError уже во время выполнения теста. То есть у команды может быть сразу две проблемы: тесты слабо проверяют ответ, а часть падений связана ещё и не с API, а с кривым деревом зависимостей.
Главный капкан, впрочем, не в Maven и не в Hamcrest. Самая неприятная ловушка спрятана в версии JSON Schema, которую реально понимает валидатор. Автор разбирает ситуацию, когда разработчик пишет красивую схему с условной логикой, ориентируясь на более новые черновики спецификации, например draft-07, а инструмент фактически валидирует по draft-04. На бумаге всё выглядит солидно: есть условия, ветвление, строгие ограничения. На практике часть правил может просто не применяться, и тест остаётся зелёным, хотя кажется строгим только визуально. Это особенно опасно для больших команд, где наличие схемы уже само по себе воспринимается как гарантия качества.
Для рынка это хороший холодный душ. За последние годы API-тестирование во многих продуктах стало быстрым и удобным, но не всегда глубоким. Команды охотно автоматизируют «счастливый путь», проверяют статус-коды, SLA и ключевые поля, а вот полноценную валидацию контракта откладывают как избыточную бюрократию. Статья OTUS бьёт ровно по этой привычке: контракт перестаёт быть абстракцией для архитекторов и превращается в работающую страховку от тихих несовместимых изменений. Для разработчиков это аргумент пересмотреть тесты, для тимлидов и QA-лидов — повод проверить, не живёт ли в проекте набор декоративных схем, которые никого и ничего не защищают.
Самый неприятный вывод здесь даже не в том, что тесты иногда врут. С этим индустрия давно смирилась. Хуже, когда команда уверена, что проверяет контракт API строго и современно, а валидатор в этот момент молча игнорирует половину логики схемы. Значит, следующий виток зрелости в API-тестировании будет не про ещё один «зелёный» прогон, а про умение доказать, что зелёный цвет действительно что-то означает.
The post REST Assured 6.0: почему зелёные тесты не ловят баги в API appeared first on iTech News.