Зачем мне имитировать вызов нашего API? Хм, давай посмотрим несколько сценариев

  • API не работает - как вы тестируете свой код, если сам API не работает
  • API изменен - ​​ вы знаете, что ваш код должен работать, но вы не знаете, что только что измененный API - это обратный вызов. Затем вы должны изменить свой код, чтобы пройти тест.
  • Вы сдались - пропустили тест функции вызова API и не заботились о том, что покрытие упадет.

Собственно, ваша задача - обработать возвращенный вызов API. И нет, нет, вы не должны тестировать свой обратный вызов API, это должно быть задачей разработчиков API.

Вот почему вам нужно имитировать вызовы API. Таким образом, ваш тест кода будет пройден, даже если API не работает, и если в API будут внесены изменения, вы сможете его реорганизовать.

Издевательство

Мокинг - это способ имитировать функцию в тесте и имитировать функцию с высокой степенью связи, например API или компонент, который использует функцию в качестве параметра. В TDD тест должен быть сосредоточен на тестировании одного функционального теста. Поэтому мы не тестируем выходные данные других функций с помощью функционального теста.

Допустим, есть функции A и B. Функцию A необходимо протестировать, и она вызывает функцию B. Предположим, функция B находится в другой службе и уже прошла проверку. Таким образом, вам не нужно повторно тестировать функцию B, и будет сложно вызвать функцию B, потому что она находится в другой службе, и службу необходимо перезапустить.

Чтобы справиться с этой проблемой, нам нужно имитировать функцию B. Мы можем имитировать функцию B, чтобы имитировать данный возвращаемый результат. Итак, мы можем сосредоточиться на тестировании функции A, не беспокоясь о функции B, потому что она уже высмеяна.

Шутка макет

Макет функции

В нашем проекте PPL мы используем фиктивную функцию, чтобы использовать ее в качестве параметра для компонента фильтра.

Мы имитируем функцию handleFilterValue(), используя jest.fn(), поэтому мы можем передать ее в качестве параметра для <DateModifiedFilter/>component, потому что функция handleFilterValue() исходит от своего родительского компонента. Таким образом, мы можем получить 100% покрытие для этого компонента, потому что нам не нужно повторно тестировать функцию handleFilterValue().

Мок API

Мы имитируем выборку JavaScript, чтобы имитировать и возвращать фиктивный вывод.

Перед издевательством мы делаем вывод Promise, потому что функция является асинхронной, затем мы передаем вывод в jest.fn()using mockImplementation(), чтобы вернуть вывод при вызове fetch. Таким образом, мы можем гарантировать, что результат будет одинаковым для всех тестов.

Затем мы делаем сам тест асинхронным и используем waitFor()function, чтобы дождаться, когда фиктивная функция вернет свой результат, потому что функция извлекает с помощью async. После каждого теста мы сбрасываем макет, чтобы убедиться, что в каждом тесте есть новый фиктивный вызов API.

Это все, что у меня есть для Mock, не забудьте прочитать мои недавние статьи.

Подводя итог, мы используем Mock для предотвращения вызова API при тестировании и ложноотрицательном тесте. Кроме того, макет может сделать тест более быстрым и надежным.