Automation QA - Собеседование на микросервисный проект (часть 2)

Коротко о видео

Это пробное мок-интервью для Automation QA на микросервисном проекте. Участники разбирают REST API: методы HTTP, параметры запроса, заголовки, коды статуса, подход к smoke-тесту и проверке JSON-ответов через Java-модели и Jackson. Во второй части обсуждаются отличие монолита от микросервисов, риски интеграций, контрактное тестирование, consumer-driven/producer-driven contracts, Pact и Spring Cloud Contract, а также границы component и end-to-end тестирования.

Затронутые темы

Что взять на заметку

• Для smoke-теста API в примере с каталогом товаров предлагают проверить позитивный GET-сценарий, HTTP status code, ограничение top-10 и содержимое ответа, а не только факт получения ответа.
• При проверке JSON обсуждают десериализацию ответа в Java-объект и настройку строгости: нужны ли только обязательные поля или ответ должен содержать ровно ожидаемую структуру без дополнительных полей.
• В учебном разборе PUT противопоставлен PATCH: PATCH изменяет часть существующего ресурса, а PUT передаёт полное представление; конкретное поведение при отсутствии ресурса следует закреплять контрактом API.
• Query-параметры полезны для фильтрации и прямых сохраняемых ссылок на ресурс или состояние; заголовки предназначены для служебных данных и не дают такого пользовательского URL.
• Микросервис следует выделять вокруг конкретной бизнес-задачи; переход от монолита добавляет стоимость интеграций, документации API и согласованности между сервисами.
• Контрактные тесты отнесены к интеграционному уровню и проверяют ожидания пары consumer–producer; добавление нового поля может быть совместимым, а изменение существующего поля, формата или ограничений — ломающим контракт.
• Pact назван инструментом для consumer-driven contracts, в том числе между UI и сервисом; Spring Cloud Contract обсуждается как инструмент, более ориентированный на producer-driven contracts.