Думаю многие сталкивались с ситуацией, когда разработка клиентской и серверной части приложения ведутся несинхронно. Фронтендеры уже готовы зарелизить что-то, а бэк отстает, или наоборот, а еще может быть что в вашем окружении нет нужных данных чтобы проверить какой-то нестандартный сценарий. В идеале конечно когда проблему с бекендом решают бекендеры, но и с позиции фронтендера эту проблему можно обходить по-разному. Самое удивительное что я для себя обнаружил, что многие люди не знают или не пользуются тем или иным способом. Вот список того что мы можем использовать: 1. Не самый хороший способ, но простой и рабочий - monkeypatch fetch. В консоли или из какого-нибудь скрипта временно переопределяете метод fetch и хардкодите возвращаемое значение: const originalFetch = window.fetch; window.fetch = async (input, init) => { const url = (typeof input === 'string') ? input : input.url; if (url.includes('/api/todos')) { return new Response(JSON.stringify([{ id: 1, title: 'Mocked task', done: false }]), { status: 200, headers: { 'Content-Type': 'application/json' } }); } return originalFetch(input, init); }; Минус тут очевиден - действует только в текущей вкладке/сессии и не работает для XHR, пока код не использует fetch (или если есть другие обёртки). 2. Local overrides. Самый быстрый способ "из коробки" - мы можем подменить содержимое ответов сервера по определенным урлам. По моему мнению самый идеальный способ для быстрого локального тестирования без внешних инструментов. Чтобы воспользоваться им открой DevTools → вкладка Sources. В панели слева найдёшь раздел Overrides (если нет — три точки → More tools → Overrides). Включи Overrides и укажи папку на диске (браузер попросит доступ). Открой Network → найди нужный запрос → правый клик → Save response (или в Sources найти файл и отредактировать). Теперь браузер будет отдавать сохранённый файл вместо реального ответа (пока включён Override). Минус этого подхода в том, что на каждый урл может быть только один файл, и если у вас много различных сценариев, то придется либо постоянно менять содержимое файла, либо переименовывать их. 3. Можно зарегистрировать локальный Service Worker, который перехватит fetch и отдаст мок: // В service-worker.js self.addEventListener('fetch', event => { const url = new URL(event.request.url); if (url.pathname === '/api/todos') { event.respondWith(new Response(JSON.stringify([{id:1, title:"SW mock"}]), { headers: {'Content-Type': 'application/json'} })); } }); Зарегистрируешь — и замена будет работать пока SW активен. Хорошо для оффлайна и стабильных сценариев тестирования. Можно сделать набор различных ответов для разных случаев и легко проверять их. 4. Ну и конечно же можно сделать это с помощью внешних инструментов: прокси и расширений. Например: mitmproxy / Charles / Fiddler - мощные прокси, позволяют править ответы и HTTPS. Отлично для комплексных сценариев и тестов. Или популярные Requestly / Mockoon / Postman - удобные GUI-инструменты/расширения для создания правил подмены. В целом инструментов для этой задачи огромное количество. Основной плюс состоит в том, что можно сделать это независимо от бекенда или других команд. С таким подходом легко покрывать ошибки и крайние случаи. Однако не забывайте об ограничениях и рисках: 1. Любой подход не заменяет полноценное интеграционное тестирование. Моки не выявят проблем с БД, авторизацией, latency, гонками транзакций и т.п. 2. Подмена данных ввести в заблуждение: если интерфейс работает только с моками - баги на реальном бекенде всплывут позже. 3. Кеширование / CORS / auth могут ломать подмены - особенно при проксировании. 4. Ну и не забывайте про безопасность - не делайте подмены на общедоступных стендах или в проде без контроля. Ставьте 🔥 если было полезно и 👍, если соскучились по таким постам. Всем продуктивного дня и хорошего настроения!