diff --git a/blog/component-testing.mdx b/blog/component-testing.mdx index 2690844..015ad70 100644 --- a/blog/component-testing.mdx +++ b/blog/component-testing.mdx @@ -11,20 +11,20 @@ import Admonition from "@theme/Admonition"; -Практически все современные веб-интерфейсы пишутся с использованием фреймворков (React, Vue, Svelte, ...) для упрощения создания, реиспользования и компоновки веб-компонентов. Такие компоненты важно тестировать в изоляции друг от друга, чтобы быть уверенным, что каждый компонент корректно справляется со своей работой. Точно так же как мы пишем unit-тесты отдельно от интеграционных. В Testplane уже поддержанно скриншотное тестирование компонентов с помощью [Storybook](https://storybook.js.org/), однако этот инструмент актуален не для всех проектов. Поэтому мы разработали ещё один вариант компонентного тестирования, который не требует использования Storybook. +Практически все современные веб-интерфейсы пишутся с использованием фреймворков (React, Vue, Svelte, ...) для упрощения создания и реиспользования компонентов. Такие компоненты важно тестировать в изоляции друг от друга, чтобы быть уверенным, что каждый компонент корректно справляется со своей работой. Точно так же как мы пишем unit-тесты отдельно от интеграционных. В Testplane уже поддержанно скриншотное тестирование компонентов с помощью [Storybook](https://storybook.js.org/), однако этот инструмент актуален не для всех проектов. Поэтому мы разработали ещё один вариант компонентного тестирования, который не требует использования Storybook. Данная возможность может быть полезна, если у вас в проекте используются React-компоненты. При этом тестов нет совсем или используются только тяжелые интеграционные тесты (т.е. проверяются целые страницы, содержащие множество компонентов). Согласно [пирамиде тестирования](https://martinfowler.com/articles/practical-test-pyramid.html), интеграционных тестов должно быть меньше всего так как они больше подвержены “флапам” и зачастую избыточны. Множество сценариев можно проверить с помощью компонентых тестов и тем самым сократить время выполнения тестов в CI и улучшить их стабильность. ### Варианты реализации компонентного тестирования -Компонентное тестирование — это вид тестирования, при котором логика работы веб-компонента проверяется в изоляции от веб-страницы, в которой он используется. Для того, чтобы выполнить такой тест, нужно уметь корректно рендерить компонент. Часто для этой задачи применяют [JSDom](https://github.com/jsdom/jsdom) (используется в [Jest](https://jestjs.io/)), который рендерит веб-компоненты с помощью виртуального рендера Node.js, т.е. без использования реального браузера. С одной стороны, это работает быстрее (браузер не поднимается), а с другой — менее стабильно, так как проверки выполняются не в реальном браузере. Второе популярное решение — это использовать очень быстрый dev-сервер [Vite](https://vitejs.dev/), который поддерживает множество фреймворков (React, Vue, Svelte, ...) и отвечает за рендер компонентов в изоляции. +Компонентное тестирование — это вид тестирования, при котором логика работы веб-компонента проверяется в изоляции от веб-страницы, в которой он используется. Для того, чтобы выполнить такой тест, нужно уметь корректно рендерить компонент. Часто для этой задачи применяют [JSDom](https://github.com/jsdom/jsdom) (используется в [Jest](https://jestjs.io/)), который рендерит веб-компоненты с помощью виртуального рендеринга Node.js, т.е. без использования реального браузера. С одной стороны, это работает быстрее (браузер не поднимается), а с другой — менее стабильно, так как проверки выполняются не в реальном браузере. Второе популярное решение — это использовать очень быстрый dev-сервер [Vite](https://vitejs.dev/), который поддерживает множество фреймворков (React, Vue, Svelte, ...) и отвечает за рендеринг компонентов в изоляции. Мы остановились на варианте с использованием Vite, так как такой подход обеспечивает тестирование страницы более приближенное к реальности (как если бы ее открыл пользователь). При этом, сами тесты выполняются немного дольше, чем в jsdom. Но для нас самое главное стабильность и воспроизводимость результатов тестов, поэтому выбор был очевиден.
- Краткая информация о том, как это реализовано под капотом + Краткая информация о том, как это реализовано - - при указании опции `testRunEnv: 'browser'` в конфиге Testplane, будет использован браузерный раннер, который под капотом поднимает Vite на localhost с рандомным свободным портом (пользователь может выставить необходимый порт в конфиге Vite). Именно на этом поднятом сервере будут рендерится все пользовательские компоненты и выполняться все необходимые команды/проверки (т.е. прямо внутри браузера); + - при указании опции `testRunEnv: 'browser'` в конфиге Testplane, будет использован браузерный раннер, который поднимает Vite на localhost с рандомным свободным портом (пользователь может выставить необходимый порт в конфиге Vite). Именно на этом поднятом сервере будут рендерится все пользовательские компоненты и выполняться все необходимые команды/проверки (т.е. прямо внутри браузера); - затем читаются тесты в Node.js, т.е. как это делается и для интеграционных тестов. Это необходимо, чтобы все плагины работали корректно (речь про триггер событий при чтении тестов), а так же, чтобы была возможность запустить тесты из одного файла параллельно. Если бы тест читался только в контексте браузера, то приходилось бы запускать абсолютно все тесты внутри одного файла и критическое завершение в одном из них приводило бы к остановке всех последующих. Т.е. на данном этапе мы понимаем какие тесты нужно запустить; - после чего, как обычно, поднимаются необходимые браузеры и в них запускаются тесты. Каждый тест перед выполнением пользовательского кода выполняет переход на поднятый сервер Vite. При выполнении такого запроса генерится специальный index.html, в который подгружаются все необходимые библиотеки: - mocha — для чтения тестов; @@ -38,7 +38,7 @@ import Admonition from "@theme/Admonition"; ### Как использовать? -Будем настраивать тестирование react-компонентов, написанных на Typescript. Поэтому, для начала установим необходимые зависимости: +Будем настраивать тестирование react-компонентов, написанных на TypeScript. Поэтому, для начала установим необходимые зависимости: ```bash npm i testplane vite @vitejs/plugin-react @testing-library/react --save-dev @@ -108,7 +108,7 @@ it("should log document", async () => { } ``` -Напишем более сложный тест с рендером react компонента: +Напишем более сложный тест с рендерингом react компонента: ```javascript // src/tests/test.testplane.tsx @@ -153,11 +153,11 @@ it("should render react button", async ({ browser }) => { В Vite поддерживается [HMR](https://vitejs.dev/guide/api-hmr.html). Это означает, что если изменить загруженный файл, то произойдет или ремаунт компонента, или полная перезагрузка страницы. В случае, если компонент описан в отдельном файле (т.е. не в одном файле с тестом), то будет выполнен ремаунт, но тест перезапущен не будет. А если изменить файл с тестом, то произойдет перезагрузка страницы, которая приведет к тому, что Testplane прервет выполнение текущего теста и запустит его заново. За счет такой возможности в Vite можно очень быстро разрабатывать компоненты и писать для них тесты. Рекомендуется использовать вместе с REPL-режимом. -На данном видео видно, что при изменении исходников компонента не происходит полного перезапуска теста (маунтится по новой только сам компонент). При этом, если изменить код теста, то происходит полный перезапуск. +При изменении исходников компонента не происходит полного перезапуска теста (маунтится по новой только сам компонент). При этом, если изменить код теста, то происходит полный перезапуск. #### Использование инстанса browser и expect прямо в DevTools браузера -Внутри браузера, в котором выполняется тест, доступны инстанс самого `browser` и инстанс `expect`. Это довольно удобно использовать при дебаге теста. +В консоли браузера, в котором выполняется тест, доступны инстанс самого `browser` и инстанс `expect`. Это довольно удобно использовать при дебаге теста. #### Логи из консоли браузера в терминале diff --git a/blog/rebranding.mdx b/blog/rebranding.mdx index cda192e..3b55ac8 100644 --- a/blog/rebranding.mdx +++ b/blog/rebranding.mdx @@ -9,16 +9,21 @@ date: 2024-05-20T13:00 -После рассмотрения всех за и против мы остановились на этом новом имени, которое, на наш взгляд, лучше всего подходит нашему продукту. Но не волнуйтесь, в самой сути ничего не изменилось. Testplane — тот же проект, который вы знали многие годы как Hermione, просто в новом обличье. Мы решили сделать сквозную нумерацию версий: Testplane v8.x — это эквивалент Hermione v8.x. +Мы долго рассматривали все за и против и пришли к выводу, что новое имя — Testplane — наилучшим образом отражает наше видение и будущее развитие продукта: -Если вы уже работаете с Hermione, обновление на Testplane должно занять не больше нескольких минут — мы проектировали его как drop-in замену: +1. Мы планируем активно вкладываться в развитие инструмента в опенсорсе. Новое имя символизирует качественный переход в развитии инструмента. +2. Мы стремимся создать полноценный бренд с товарным знаком, логотипом, фирменным визуальным стилем. Testplane — это название, которое как сочетает в себе отсылку к «испытательному полету», так и может читаться как "плоскость для тестирования". -- умеет работать с существующими плагинами hermione -- понимает все опции и переменные окружения hermione -- конфиги полностью совместимы -- предоставляет сразу 2 бинаря (testplane и hermione) для плавного переезда (т.е. можно запускать и как `hermione gui`, и как `testplane gui`) -- для TS экспортирует и свои типы, и типы hermione (в т.ч. hermioneCtx) +Суть продукта остаётся неизменной. Testplane — это тот же проект, который вы знали многие годы как Hermione, но в свежем, обновленном виде. Чтобы упростить переход, мы решили сохранить сквозную нумерацию версий: Testplane v8.x — это эквивалент Hermione v8.x. -Если же вы еще не пробовали Testplane — загляните в документацию и начните путешествие с Testplane всего за пару минут! +Если вы уже работаете с Hermione, обновление на Testplane займет всего несколько минут. Мы проектировали его как drop-in замену: -Спасибо вам за то, что остаётесь с нами! ✈️ +- Полная поддержка существующих плагинов Hermione. +- Понимание всех опций и переменных окружения Hermione. +- Полная совместимость конфигураций. +- Два бинарных файла (testplane и hermione) для плавного перехода (вы можете запускать и как hermione gui, и как testplane gui). +- Экспорт типов для TypeScript, включая как собственные типы Testplane, так и типы Hermione (включая hermioneCtx). + +Если же вы еще не пробовали Testplane — загляните в нашу документацию и начните ваше исследование с Testplane всего за пару минут! + +Благодарим за интерес к проекту! ✈️ diff --git a/docs/commands/browser/$$.mdx b/docs/commands/browser/$$.mdx index a27451f..39d7494 100644 --- a/docs/commands/browser/$$.mdx +++ b/docs/commands/browser/$$.mdx @@ -37,7 +37,7 @@ await browser.$$(selector); **index.html** -```javascript +```html