Учитывая, насколько слабо связана веб-разработка в наши дни, что приводит к разделению внешнего интерфейса (в основном SPA) и внутреннего интерфейса (на основе API) наших приложений и часто обрабатывается разными командами, необходимо учитывать одну важную вещь: «Заблокированный фактор».
Фактор блокировки - это время, которое разработчик тратит в ожидании зависимостей внешнего API, тем самым предотвращая разработку функции во внешнем интерфейсе или в проекте в целом.
Издевательство - выход из этого заблокированного фактора. Они просты в написании, гибки и не сохраняют состояние (следовательно, многократно тестировать сценарии проще) и, в конечном итоге, обеспечивают выход из зависимостей внешнего API.
Мокинг позволяет нам моделировать серверный API, указывая конечные точки и ответы, которые они дают.
Фреймворк Mocking
В этой статье я продемонстрирую, как использовать MSW (Mock Server Worker) для имитации API для приложения todo response.
Mock Service Worker - это библиотека имитации API, которая использует API Service Worker для перехвата реальных запросов. - mswjs.io
Примечание: MSW полностью не зависит от платформы, а также поддерживает GraphQL. Вам стоит это увидеть!
Давайте начнем!
Нам нужно установить MSW.
Затем нужно будет настроить макеты. Я отделяю действия API, такие как создание, чтение и т. Д., От самих фиктивных серверов только для удобства.
Давайте сделаем это.
Теперь мы можем создать наш макет.
Если вы знакомы с экспресс-структурой node.js, способ написания макета REST API с помощью MSW аналогичен.
Выше мы определили все REST API с их ответами, и, если вы заметили, все наши конечные точки REST указывают на HTTPS-сервер (префикс apiUrl). Это связано с тем, что сервис-воркеры должны обслуживаться по HTTPS, а не по HTTP (всегда учтите это).
Мы могли бы прикрепить статус ответа, JSON, и т. Д., Что отлично и похоже на то, как наши API-интерфейсы ведут себя нормально.
SetupWorker или обработчик еще не запущен; следовательно, API сервис-воркера не будет перехватывать запросы. Мы запустим воркер в режиме разработки, потому что мы не хотим использовать имитацию в продакшене или даже при постановке.
Давайте сделаем это.
Все, что нам нужно сделать, это импортировать указанный выше файл в точку входа нашего приложения.
//index.ts import './server'
Теперь, когда мы запускаем наше приложение для реагирования, мы должны увидеть в консоли браузера следующее.
Потрясающий!
Если мы сделаем запрос API к конечной точке «/ todo / all» и посмотрим на вкладку «Сеть», мы увидим фактический запрос и соответствующий ответ, предоставленный службой. рабочий API.
И мы получим данные задач из нашего todoDB.json.
Это замечательно, поскольку у нас нет готовой серверной части и многого другого; Мы не сталкиваемся с какими-либо препятствиями в нашем процессе разработки как фронтенд-разработчики.
Одна из основных проблем, связанных с использованием моков, - это обслуживание, так как поведение серверной части может быстро измениться, и мы должны поддерживать моки. Это верный момент, но если мы должны написать тесты (мы сделаем это во второй части этой статьи) для потребления этих API на интерфейсе, нам все равно придется поддерживать наши макеты, учитывая, что наши пользователи не будут имитировать выборку. или Axios, следовательно, наш тест тоже не должен, что, если есть способ разделить обработчики между сервером разработки и тестовым сервером, следовательно, поддерживая только один обработчик и действия API.
В следующей статье мы еще больше рассмотрим возможности MSW.
Спасибо за чтение.
