Как тестировать WebSocket соединения в Playwright
Тестировать REST умеют все. А что делать, если приложение использует WebSocket для real-time данных?
Чат, live-нотификации, дашборд с ценами — это всё websocket. И у большинства команд это белое пятно в автоматизации. Playwright умеет работать с WebSocket — показываю три сценария.
Сценарий 1: Прослушать и проассертить WS-сообщения test('получаем уведомление о новом заказе', async ({ page }) => { const messages: string[] = [];
page.on('websocket', ws => { ws.on('framereceived', ({ payload }) => { messages.push(payload.toString()); }); });
await page.goto('/dashboard'); await page.click('[data-testid="create-order"]');
// Ждём конкретное WS-сообщение await expect.poll(() => messages).toContainEqual( expect.stringContaining('"type":"order_created"') ); });
Сценарий 2: Мокировать WS-сервер (Playwright 1.40+) test('показывает алерт при разрыве соединения', async ({ page }) => { await page.routeWebSocket('wss://api.example.com/ws', ws => { ws.onMessage(msg => { ws.send(JSON.stringify({ type: 'pong' })); }); // Закрываем соединение через секунду setTimeout(() => ws.close(), 1000); });
await page.goto('/dashboard'); await expect(page.locator('.connection-error')).toBeVisible(); });
Сценарий 3: Коллектировать и проверять после действия
Ключевой нюанс: подписку на WS нужно регистрировать до page.goto(). Если сделать после — первые фреймы уже пропущены.
// ✅ Правильно page.on('websocket', ws => { /* ... */ }); await page.goto('/app');
// ❌ Неправильно — WS уже открыт await page.goto('/app'); page.on('websocket', ws => { /* ... */ });
Это самый частый баг при первом знакомстве с WS-тестами в Playwright.
Тестируете ли вы real-time функциональность автоматически или это всегда ручное тестирование? У меня в текущем проекте покрыто около 60% WS-сценариев — хотел бы больше, но времени не хватает.
#playwright #typescript #testing #websocket #sdet @haradkou_sdet
· 22.04
Полезная шпаргалка. Добавлю паттерн который часто упускают: мок WebSocket-сервера для изоляции тестов. Вместо реального бэкенда — intercepting через page.route для ws:// + page.on("websocket"). Это даёт стабильные тесты без flakiness от сетевых задержек. Ещё важный сценарий: тест на reconnect — отключить WS через page.evaluate, убедиться что клиент переподключился и восстановил состояние. Это проверяет resilience реального приложения, не только happy path.
ответить
коммент удалён