Такой интеграционный тест вызывает API с уникальными данными и затем ограниченно ждёт соответствующее событие в Kafka, проверяя ключ, контракт и связь с запросом.
Моки ускоряют и стабилизируют тесты, позволяют воспроизводить редкие ошибки и не обращаться к платным сервисам, но могут разойтись с реальным контрактом.
Возможны собственные тестовые DTO, модели разработчиков и проверки отдельных JSON-полей; выбор зависит от независимости теста и того, какую часть контракта он проверяет.
Нужно подтвердить фактическую схему: кто владеет тестами, где они хранятся и как согласуют изменения. Кросс-функциональность команды не обязательно означает один репозиторий.
Да, frontend может обращаться к внешнему API, если это допускают контракт, CORS и модель безопасности. Секреты приложения обычно требуют обращения через backend.
В конспекте следует использовать термины «ООП» и «наследование». Пример Dog/Cat показывает полиморфизм, а Git — отдельную тему, не принцип объектного подхода.
Кроме REST встречаются SOAP, GraphQL, RPC и событийные API. POST технически может запускать удаление, но стандартная HTTP-семантика удаления ресурса выражается DELETE.
Тест скрыт постоянным skip и недостаточно надёжен: нужны timeout, проверка GET-статуса, согласованная авторизация, уникальные данные, очистка и ясный контракт идентификатора.
Альтернативы включают GraphQL, SOAP, JSON-RPC, WebSocket и обмен сообщениями через брокер. Они решают разные задачи и не всегда заменяют REST или gRPC напрямую.
Считайте число активных операций и его максимум. Значение peak больше единицы подтверждает перекрытие клиентских операций; одно лишь короткое общее время не является достаточным доказательством.
Для MVP достаточно модульного backend, PostgreSQL и объектного хранилища изображений. Категории и допустимые атрибуты храните отдельно от пользовательских публикаций.
Представьте модели как версионируемые ресурсы, а длительные inference/evaluation — как отдельные задания со статусами. Удаление и изменение должны проверять ownership.