Почему заглушка? При написании модульных тестов мы часто хотим заглушить части кода, которые нам не интересны. Заглушка - это просто часть кода, заменяющая другую. Допустим, вы пишете тест для <UserContainer> компонента. Это выглядит так:

<UsersDisplay> имеет created метод жизненного цикла, подобный этому:

Мы хотим написать тест, который утверждает, что рендеринг <UsersDisplay>.

axios делает запрос ajax к внешней службе в ловушке created. Это означает, что когда вы делаете mount(UserContainer), <UsersDisplay> также монтируется, и created инициирует запрос ajax. Поскольку это модульный тест, нас интересует только то, правильно ли <UserContainer> отображает <UsersDisplay> - проверка запуска запроса ajax с правильной конечной точкой и т. Д. Является обязанностью <UsersDisplay>, которая должна быть протестирована в <UsersDisplay> тестовом файле.

Один из способов предотвратить запуск <UsersDisplay> запроса ajax - это заглушить компонент. Давайте напишем наши собственные компоненты и тесты, чтобы лучше понять, как разные способы и преимущества использования заглушек.

Создание компонентов

В этом примере будут использоваться два компонента. Первый - это ParentWithAPICallChild, который просто отображает другой компонент:

<ParentWithAPICallChild> - простой компонент. Его исключительная ответственность - визуализировать <ComponentWithAsyncCall>. <ComponentWithAsyncCall>, как следует из названия, выполняет вызов ajax, используя axios http-клиент:

<ComponentWithAsyncCall> вызывает makeApiCall в ловушке created жизненного цикла.

Напишите тест, используя mount

Начнем с написания теста, чтобы проверить, отображается ли <ComponentWithAsyncCall>:

Запуск yarn test:unit дает:

Тест пройден - отлично! Однако мы можем добиться большего. Обратите внимание на console.log в выходных данных теста - это исходит от метода makeApiCall. В идеале мы не хотим выполнять вызовы внешних сервисов в наших модульных тестах, особенно когда это делается из компонента, который не является основным в текущем тесте. Мы можем использовать stubs вариант монтажа, описанный в vue-test-utils документации здесь.

Использование stubs для заглушки <ComponentWithAsyncCall>

Давайте обновим тест, на этот раз заглушив <ComponentWithAsyncCall>:

Тест все еще проходит, когда запущен yarn test:unit, однако console.log нигде не видно. Это потому, что при передаче [component]: true в stubs исходный компонент заменяется заглушкой. Внешний интерфейс остался прежним (мы все еще можем выбрать использование find, поскольку свойство name, которое используется внутри find, остается прежним). Внутренние методы, такие как makeApiCall, заменяются фиктивными методами, которые ничего не делают - они «заглушены».

Вы также можете указать разметку для заглушки, если хотите:

Автоматическая заглушка с shallowMount

Вместо использования mount и вставки заглушек вручную <ComponentWithAsyncCall> мы можем просто использовать shallowMount, который по умолчанию автоматически заглушает любые другие компоненты. Тест с shallowMount выглядит так:

Запуск yarn test:unit не показывает никаких console.log, и тест проходит. shallowMount автоматически вставляется <ComponentWithAsyncCall>. shallowMount полезен для тестирования компонентов, которые имеют множество дочерних компонентов, поведение которых может запускаться в хуках жизненного цикла, таких как created или mounted и т. Д. Я обычно использую shallowMount по умолчанию, если у меня нет веской причины использовать mount. Это зависит от вашего варианта использования и того, что вы тестируете.

Заключение

  • stubs полезен для подавления поведения детей, не связанного с текущим модульным тестом.
  • shallowMount по умолчанию исключает дочерние компоненты
  • вы можете передать true, чтобы создать заглушку по умолчанию, или передать свою собственную реализацию

Вы можете найти тест, описанный на этой странице здесь.