🔌 WebSocket API автотесты на Python: не hello world, а production

Отличная статья на Хабре — Никита Филонов разбирает, как тестировать REST + WebSocket вместе, а не по отдельности.

❓ В чём проблема?
Обычно WebSocket тестируют изолированно: подключились → отправили → получили. HTTP живёт отдельно. Но в реальных сервисах это один сценарий: пользователь регистрируется через REST, подключается к WebSocket, отправляет сообщение, остальные получают событие.

🔑 Ключевая идея — контрактный подход
Тесты проверяют не «пришла строка из сокета», а модель взаимодействия. Все входящие/исходящие события — Pydantic-модели. Никаких json.loads и ручных проверок ключей.

🏗 Архитектура тестового слоя:
• Базовый HTTP-клиент → предметные клиенты (UsersHTTPClient, SystemHTTPClient)
• Базовый WebSocket-клиент → ChatWSClient
• Все запросы через Allure-шаги
• URL из pydantic-settings, не хардкодятся

💡 Что особенно полезно:
1. Разделение методов на *_api (возвращает Response) и высокоуровневые (возвращают Pydantic-модель)
2. WebSocket-события — единая модель WSOutgoingEvent с type + опциональными полями
3. Faker для генерации тестовых данных прямо в схемах
4. Сброс состояния через POST /api/reset в autouse-фикстуре
5. Модели в tests/ не импортируются из app/ — тесты как независимый потребитель API

📦 Стек: FastAPI + pytest + pytest-asyncio + httpx + websockets + allure-pytest + Faker

👉 Читать полностью на Хабре

#QA #Тестирование #Python #WebSocket #API #Автотесты #FastAPI #QA4Life