опыта очень в тестировании. вопрос следующий, как тестировать запросы. Основная проблема в том, что бэк может менять структуру ответа, а на фронте это может быть критично. Нам необходимо проверять тестами, что структура ответа соответствует той, которую мы пропишем в тесте.
покрывает ли эту потребность плагин 'jest-fetch-mock' с его моковыми запросами? например, я задаю изначально ожидаемый результат, на отправленный payload и потом сверяю, что ответ равен моему ожидаемому результату и свойства объекта равны
expect(task).toEqual(expect.objectContaining(responseData))
Этот тест упадет, если в реальности бэк поменяет структу ответа? как я могу в этом убедиться?
как второй вариант, я тестирую реальный запрос, где тест точно упадет, если вдруг что. Но, при запуске теста у меня создается реальная задача и я вижу ее на фронте.
как правильно?
без шуток - здесь не нужно писать никакой тест. С бекендом заранее оговаривается интерфейс взаимодействия - «контракт», желательно в виде документа openapi 2.0/swagger, где описываются все эндпоинты бекенда. Со стороны фронтенда задача - рисовать красоту по этому «контракту». Со стороны бекенда задача - реализовывать этот «контракт». Если бекенд начинает присылать что-то другое в ответах на свои ручки - значит он не делает свою работу - не реализует «контракт» Тестить, что бекенд возвращает респонсы по контракту - задача бекенда
о, спасибо большое,я возьму это как аргумент для отстаивания моковых данных
вы собственно и мок нормальный не можете написать, если у вас нет контракта зафиксированного. Пока на бумаге нет явно указанного интерфейса ответа - это все ваши догадки А когда уже есть конртакт с бекендом - можно и моки писать; И тестить ровно работу фронтенда - «Я правильно отрисовал то что хотел», «когда нажал на кнопку - вызвалась правильная ручка»
Обсуждают сегодня