Коли ти вперше відкриваєш вкладку Network у DevTools і бачиш там WebSocket-з'єднання — здається, що все під контролем. Є список фреймів, є напрямок, є payload. Що ще потрібно?
Але це відчуття зникає в момент, коли потрібно щось реально зробити з цими даними.
Що DevTools вміє — і де зупиняється
Chrome DevTools у вкладці Network показує WS-трафік у пасивному режимі: фрейми відображаються, але лише як читання. Жодного втручання, жодної модифікації, жодної можливості перевірити — а що буде, якщо сервер отримає ось цей payload замість того?
Для будь-якого реального тестування сценарій виглядає так:
Потрібен Wireshark або mitmproxy — а це налаштування сертифікатів, проксі, можливо окрема машина
Або пишеш окремий скрипт — Node, Python, whatever — який підключається до того ж сокету і відправляє тестові повідомлення
Або копаєшся у вихідному коді і додаєш логування вручну
Жоден із цих варіантів не підходить для швидкої перевірки під час розробки або QA.
Де це реально болить
Уяви типову ситуацію: у тебе є фронтенд із WebSocket-підключенням до бекенду. Під час QA треба перевірити, як компонент поводиться, якщо сервер надсилає нестандартний payload — наприклад, порожній об'єкт, або рядок замість числа, або відповідь із затримкою.
Варіанти:
Просити бекенд-розробника тимчасово змінити логіку сервера
Писати мок-сервер
Модифікувати фронтенд-код перед тестом (і не забути відкатити)
Усе це — зайвий час і зайвий ризик щось зламати.
Інший підхід: розширення замість зовнішніх інструментів
Ідея проста: якщо браузер вже бачить весь WS-трафік — чому б не дати йому можливість його модифікувати? Не через проксі ззовні, а прямо всередині.
Розширення Chrome може виступати як прозорий проксі між сторінкою і сокетом. Кожен вихідний фрейм проходить через нього — і там можна встановити правила заміни. Без змін у коді, без налаштувань, без перезапуску.
Що це дає на практиці
Для QA: перевіряти edge cases без залучення бекенду. Хочеш побачити, що станеться якщо сервер відправить null у полі userId? Налаштовуєш правило підміни — і тестуєш.
Для розробника: бачити кожен фрейм у реальному часі прямо в side panel, не переключаючись між вкладками DevTools.
Для security-ресерчу: моніторити WS-трафік будь-якого сайту в браузері — без додаткового софту.
Поточний стан і що далі
Зараз підтримується модифікація вихідних повідомлень (client → server). У планах — підміна вхідних (server → client), вбудований WS-клієнт для надсилання довільних повідомлень, і базова автоматизація тестів.
Розширення безплатне. Код відкритий.
Якщо займаєшся QA або розробкою фронтенду з WebSocket — спробуй: https://tests.ws/extension. Якщо є питання або баг — пиши.
