Компонентное тестирование

В testplane в экспериментальном режиме поддержали компонентное тестирование и unit-тесты, выполняющиеся в браузере.

Практически все современные веб-интерфейсы пишутся с использованием фреймворков (React, Vue, Svelte, ...) для упрощения создания и реиспользования компонентов. Такие компоненты важно тестировать в изоляции друг от друга, чтобы быть уверенным, что каждый компонент корректно справляется со своей работой. Точно так же как мы пишем unit-тесты отдельно от интеграционных. В Testplane уже поддержанно скриншотное тестирование компонентов с помощью Storybook, однако этот инструмент актуален не для всех проектов. Поэтому мы разработали ещё один вариант компонентного тестирования, который не требует использования Storybook.

Данная возможность может быть полезна, если у вас в проекте используются React-компоненты. При этом тестов нет совсем или используются только тяжелые интеграционные тесты (т.е. проверяются целые страницы, содержащие множество компонентов). Согласно пирамиде тестирования, интеграционных тестов должно быть меньше всего так как они больше подвержены “флапам” и зачастую избыточны. Множество сценариев можно проверить с помощью компонентых тестов и тем самым сократить время выполнения тестов в CI и улучшить их стабильность.

Варианты реализации компонентного тестирования

Компонентное тестирование — это вид тестирования, при котором логика работы веб-компонента проверяется в изоляции от веб-страницы, в которой он используется. Для того, чтобы выполнить такой тест, нужно уметь корректно рендерить компонент. Часто для этой задачи применяют JSDom (используется в Jest), который рендерит веб-компоненты с помощью виртуального рендеринга Node.js, т.е. без использования реального браузера. С одной стороны, это работает быстрее (браузер не поднимается), а с другой — менее стабильно, так как проверки выполняются не в реальном браузере. Второе популярное решение — это использовать очень быстрый dev-сервер Vite, который поддерживает множество фреймворков (React, Vue, Svelte, ...) и отвечает за рендеринг компонентов в изоляции.

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

Краткая информация о том, как это реализовано

• при указании опции testRunEnv: 'browser' в конфиге Testplane, будет использован браузерный раннер, который поднимает Vite на localhost с рандомным свободным портом (пользователь может выставить необходимый порт в конфиге Vite). Именно на этом поднятом сервере будут рендерится все пользовательские компоненты и выполняться все необходимые команды/проверки (т.е. прямо внутри браузера);
• затем читаются тесты в Node.js, т.е. как это делается и для интеграционных тестов. Это необходимо, чтобы все плагины работали корректно (речь про триггер событий при чтении тестов), а так же, чтобы была возможность запустить тесты из одного файла параллельно. Если бы тест читался только в контексте браузера, то приходилось бы запускать абсолютно все тесты внутри одного файла и критическое завершение в одном из них приводило бы к остановке всех последующих. Т.е. на данном этапе мы понимаем какие тесты нужно запустить;
• после чего, как обычно, поднимаются необходимые браузеры и в них запускаются тесты. Каждый тест перед выполнением пользовательского кода выполняет переход на поднятый сервер Vite. При выполнении такого запроса генерится специальный index.html, в который подгружаются все необходимые библиотеки:
• mocha — для чтения тестов;
• webdriverio — для использования инстанса браузера внутри самого браузера;
• expect — для выполнения проверок;
• и прочие внутренние модули, необходимые для корректной работы.
• при открытии index.html из Vite, браузер устанавливает websocket-соединение с мастер процессом Testplane для того, чтобы обмениваться необходимыми данными. Например, в случае, если в браузере вызывается конструкция await browser.$("body").assertView("plain", "body"), то очевидно, что она выполниться в самом браузере не может, так как внутри assertView нам необходим доступ к файловой системе. Поэтому, выполнение этой команды отправляется в мастер Testplane, который в свою очередь отправляет ее worker-у, в котором данный тест запущен. И именно worker выполняет переданную ему команду. Когда результат получен, он таким же образом отправляется назад в браузер. Все общение реализовано с помощью библиотеки socket.io;
• после чего, в браузере начинает выполняться указанный тест, который по завершению возвращает результат в Node.js процесс.

Как использовать?

Узнайте больше об этом в нашей документации Компонентное тестирование.

Заключение

Данная функциональность предоставляет нашим пользователям новые возможности:

• изолированное тестирование React-компонентов в реальном браузере;
• стабильность и воспроизводимость результатов тестов в сравнении с JSDom;
• поддержка HMR;
• доступ к инстансам browser/expect в DevTools браузера, для удобного дебага;
• отображение логов в терминале для повышения комфорта и увеличения скорости разработки.

Переезжайте на Testplane и попробуйте новую возможность самостоятельно. В случае обнаружения проблем, приходите в issue github — мы вам обязательно поможем!