Comments 5
Мы знали, что моки клиента — не лучшее решение, особенно, если это будет тесно связано с деталями реализации поверх поверх Амплифай, от которых мы хотели избавиться.
А точно под ссылкой "не лучшее решение" - просто гитхаб мокосервисы? Там где-то у них самокритика, прямо в гитхабе?
(не искала пока, из подозрения, что ссылка не та попала)
Да, действительно, при публикации ссылкой ошиблись. Поправили. Спасибо!
Вот корректная: https://kentcdodds.com/blog/stop-mocking-fetch
Подход имеет право на жизнь, но можно сделать гораздо проще и вынести запросы к API в отдельный слой, назовем его ApiClient. Для интеграционных тестов используем TestApiClient с тем-же интерфейсом.
Плюсы:
Через год, когда станет модно использовать другие инструменты для тестирования/удаленных вызовов, изменению подвергается только ApiClient
Максимально простая реализация
Минимум внешних инструментов
Минусы:
TestApiClient это фактически упрощенная реализация бекенда, то есть дополнительная работа и потенциальные ошибки / несоответствия
Двойная работа, изменения интерфейса ApiClient должны быть продублированы в TestApiClient
Если при использовании эмуляции сервера легко замокать какой-то отдельный запрос для отдельного теста, с TestApiClient надо либо реализовать логику внутри, либо городить интерфейс, который позволяет влиять на поведение TestApiClient из кода теста
Я, конечно, предвзят, но попробую разобрать плюсы/минусы предоставленные выше.
(Большинство моих комментариев уже было упомянуто автором выше, я лишь попробую дать более развернутый ответ для других читателей).
Через год, когда станет модно использовать другие инструменты для тестирования/удаленных вызовов, изменению подвергается только ApiClient
MSW уже около четырех лет и пока нет даже схожих библиотек по принципу перехвата запросов. Большинство продолжает работать через стабы fetch и других клиентов. Не говоря уже о том, что нет ни одного подобного инструмента позволяющего переиспользовать моки между окружениями.
Не спорю, что рано или поздно найдутся новые подходы, и если библиотека продолжить стоять на месте то естественно канет в лету. Однако судя по постоянному росту в использовании, я бы не рассматривал применение библиотеки через призму времени.
Касательно того, что "изменению подвергается только ApiClient", сам по себе MSW достаточно аккуратно абстрагирован он деталей Вашего приложения. Чего нельзя сказать о любого рода тестовых клиентах—они по определению ближе к слою взаимодействия с API нежели к непосредственно сети. Это подвергает их гораздо более частым изменениям связанными с изменениями подлежащего API в сравнении с MSW.
Максимально простая реализация
Исходя из предыдущего пункта, простота реализации тестового клиента напрямую зависит от реализации самого клиента из-за непосредственной связи между ними. Другими словами: чем сложнее настоящий клиент, тем сложнее будет и его моковая "тестовая" реализация. Как раз здесь MSW и превосходит такие клиенты, поскольку библиотеке все равно как запрашиваются и обрабатываются данные (будь то apiClient.getUser или apiClient.users.getById() через год), реализация моков через данную библиотеку останется идентична, в отличии от тестового клиента.
Минимум внешних инструментов
Это отличный аргумент. В целом, я всегда предпочту внутреннее решение если оно поддерживается. Исходя из моей практики, у компаний нет ресурсов чтобы худо-бедно набросать такое решение, не говоря уже о его достаточном тестировании и поддержке. Если у читателя такие ресурсы имеются—можете избавиться от лишней зависимости. Если нет, то переизобретать велосипед, пожалуй, не самая лучшая идея.
При надлежащем внимании и использовании строгой типизации можно достичь неплохих результатов и с тестовым клиентом. Однако это не уберет основных недостатков в виду его связи с имплементацией, что сказывается на скорости и качестве поддержки таких моков.
Использование фейкового сервера для тестирования UI (и не только)