Как и любое приложение, ваше новое приложение Vue может давать сбои по разным причинам, и важно, чтобы вы могли выявить эти проблемы и исправить их перед выпуском.

В этом руководстве мы рассмотрим базовую терминологию и дадим рекомендации о том, какие инструменты выбрать для вашего приложения Vue 3.

Когда дело доходит до тестирования составных компонентов, мы можем разделить их на две категории: составные объекты, которые не полагаются на экземпляр хост-компонента, и составные объекты, которые это делают

Если компонуемый объект использует только API-интерфейсы реактивности, то его можно протестировать, напрямую вызвав его и подтвердив возвращаемое состояние/методы:

Компонуемый объект, который опирается на перехватчики жизненного цикла или Provide/Inject, должен быть обернут в хост-компонент для тестирования. Мы можем создать помощника, как показано ниже

Каждый тип тестирования играет свою роль в стратегии тестирования вашего приложения, и каждый из них защитит вас от различных типов проблем.

Модульные тесты пишутся для проверки того, что небольшие изолированные блоки кода работают должным образом. Модульный тест обычно охватывает одну функцию, класс, составной элемент или модуль. Модульные тесты фокусируются на логической корректности и касаются лишь небольшой части общей функциональности приложения. Они могут имитировать большие части среды вашего приложения (например, исходное состояние, сложные классы, сторонние модули и сетевые запросы).

Возьмем, к примеру, эту increment функцию

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

Если какое-либо из этих утверждений терпит неудачу, ясно, что проблема содержится внутри функции increment

Как упоминалось ранее, модульное тестирование обычно применяется к автономной бизнес-логике, компонентам, классам, модулям или функциям, которые не связаны с рендерингом пользовательского интерфейса, сетевыми запросами или другими проблемами окружающей среды.

Обычно это простые модули JavaScript/TypeScript, не связанные с Vue. В целом написание модульных тестов для бизнес-логики в приложениях Vue существенно не отличается от приложений, использующих другие фреймворки.

В приложениях Vue компоненты являются основными строительными блоками пользовательского интерфейса. Таким образом, компоненты являются естественной единицей изоляции, когда дело доходит до проверки поведения вашего приложения. С точки зрения детализации тестирование компонентов находится где-то выше модульного тестирования и может рассматриваться как форма интеграционного тестирования. Большая часть вашего приложения Vue должна быть подвергнута тестированию компонентов, и мы рекомендуем, чтобы у каждого компонента Vue был собственный файл спецификаций.

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

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

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

Основные различия между Vitest и браузерными раннерами — это скорость и контекст выполнения. Короче говоря, средства запуска на основе браузера, такие как Cypress, могут обнаруживать проблемы, которые не могут обнаружить средства запуска на основе узлов, такие как Vitest (например, проблемы со стилем, настоящие собственные события DOM, файлы cookie, локальное хранилище и сбои сети), но средства запуска на основе браузера на несколько порядков медленнее, чем Vitest, потому что они открывают браузер, компилируют ваши таблицы стилей и многое другое. Cypress — это браузерный раннер, поддерживающий тестирование компонентов.

Тестирование компонентов часто включает в себя изолированное монтирование тестируемого компонента, запуск имитируемых событий пользовательского ввода и утверждение отображаемых выходных данных DOM. Существуют специальные библиотеки утилит, которые упрощают эти задачи

@vue/test-utils — это официальная библиотека низкоуровневого тестирования компонентов, написанная для предоставления пользователям доступа к API-интерфейсам Vue. Это также библиотека нижнего уровня, @testing-library/vue построенная поверх нее.

@testing-library/vue — это библиотека тестирования Vue, ориентированная на тестирование компонентов, не полагаясь на детали реализации. Его руководящий принцип заключается в том, что чем больше тесты напоминают способ использования программного обеспечения, тем больше уверенности они могут обеспечить.

Рекомендуем использовать @vue/test-utils для тестирования компонентов в приложениях. @testing-library/vue имеет проблемы с тестированием асинхронного компонента с помощью Suspense, поэтому его следует использовать с осторожностью.

Хотя модульные тесты дают разработчикам некоторую степень уверенности, модульные и компонентные тесты ограничены в своих возможностях обеспечить целостное покрытие приложения при его развертывании в рабочей среде. В результате сквозные тесты (E2E) охватывают, возможно, самый важный аспект приложения: что происходит, когда пользователи действительно используют ваши приложения.

Сквозные тесты фокусируются на поведении многостраничных приложений, которые отправляют сетевые запросы к вашему рабочему приложению Vue. Они часто включают в себя работу с базой данных или другим серверным компонентом и могут даже выполняться в живой промежуточной среде.

Сквозные тесты часто выявляют проблемы с вашим маршрутизатором, библиотекой управления состоянием, компонентами верхнего уровня (например, приложением или макетом), общедоступными активами или любой обработкой запросов. Как указано выше, они выявляют критические проблемы, которые невозможно выявить с помощью модульных или компонентных тестов.

Сквозные тесты не импортируют какой-либо код вашего приложения Vue, а вместо этого полностью полагаются на тестирование вашего приложения путем навигации по целым страницам в реальном браузере.

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

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

В то время как сквозное (E2E) тестирование в сети приобрело негативную репутацию из-за ненадежных (ненадежных) тестов и замедления процессов разработки, современные инструменты E2E добились успехов в создании более надежных, интерактивных и полезных тестов. При выборе среды тестирования E2E в следующих разделах представлены некоторые рекомендации о том, что следует учитывать при выборе среды тестирования для вашего приложения.

Одним из основных преимуществ сквозного (E2E) тестирования является возможность тестировать ваше приложение в нескольких браузерах. Хотя может показаться желательным обеспечить 100% кроссбраузерность, важно отметить, что кроссбраузерное тестирование снижает отдачу от ресурсов команды из-за дополнительного времени и мощности компьютера, необходимых для его последовательного выполнения. В результате важно помнить об этом компромиссе при выборе объема кроссбраузерного тестирования, необходимого вашему приложению.

Одна из основных проблем комплексного (E2E) тестирования и разработки заключается в том, что запуск всего пакета занимает много времени. Обычно это делается только в конвейерах непрерывной интеграции и развертывания (CI/CD). Современные среды тестирования E2E помогли решить эту проблему, добавив такие функции, как распараллеливание, которое позволяет конвейерам CI/CD часто работать намного быстрее, чем раньше. Кроме того, при локальной разработке возможность выборочного запуска одного теста для страницы, над которой вы работаете, а также обеспечение «горячей» перезагрузки тестов может помочь улучшить рабочий процесс и производительность разработчика.

В то время как разработчики традиционно полагались на сканирование журналов в окне терминала, чтобы определить, что пошло не так в тесте, современные среды сквозного тестирования (E2E) позволяют разработчикам использовать инструменты, с которыми они уже знакомы, например инструменты разработчика браузера.

Когда сквозные (E2E) тесты запускаются в конвейерах непрерывной интеграции/развертывания, они часто запускаются в автономных браузерах (т. е. ни один видимый браузер не открывается для просмотра пользователем). Важнейшей особенностью современных сред тестирования E2E является возможность просматривать снимки и/или видео приложения во время тестирования, что дает некоторое представление о том, почему происходят ошибки. Исторически сложилось так, что поддерживать такую ​​интеграцию было утомительно.

В целом, мы считаем, что Cypress предоставляет наиболее полное решение E2E с такими функциями, как информативный графический интерфейс, отличная возможность отладки, встроенные утверждения и заглушки, устойчивость к взлому, параллелизация и снимки. Как упоминалось выше, он также обеспечивает поддержку тестирования компонентов . Однако он поддерживает только браузеры на базе Chromium и Firefox.