Почему заглушка? При написании модульных тестов мы часто хотим заглушить части кода, которые нам не интересны. Заглушка - это просто часть кода, заменяющая другую. Допустим, вы пишете тест для <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
, чтобы создать заглушку по умолчанию, или передать свою собственную реализацию
Вы можете найти тест, описанный на этой странице здесь.