fix: review issues

blog/component-testing.mdx

@@ -11,20 +11,20 @@ import Admonition from "@theme/Admonition";
 
 <!-- truncate -->
 
-Практически все современные веб-интерфейсы пишутся с использованием фреймворков (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. Но для нас самое главное стабильность и воспроизводимость результатов тестов, поэтому выбор был очевиден.
 
 <details>
-    <summary>Краткая информация о том, как это реализовано под капотом</summary>
+    <summary>Краткая информация о том, как это реализовано</summary>
 
-    - при указании опции `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`. Это довольно удобно использовать при дебаге теста.
 
 #### Логи из консоли браузера в терминале
 

blog/rebranding.mdx

@@ -9,16 +9,21 @@ date: 2024-05-20T13:00
 
 <!-- truncate -->
 
-После рассмотрения всех за и против мы остановились на этом новом имени, которое, на наш взгляд, лучше всего подходит нашему продукту. Но не волнуйтесь, в самой сути ничего не изменилось. 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 всего за пару минут!
+
+Благодарим за интерес к проекту! ✈️

docs/commands/browser/$$.mdx

@@ -37,7 +37,7 @@ await browser.$$(selector);
 
 **index.html**
 
-```javascript
+```html
 <ul id="menu">
     <li>
         <a href="/">Home</a>
@@ -83,5 +83,5 @@ it("should get text a menu link - JS Function", async ({ browser }) => {
 -   [element.$](../element/$)
 -   [element.$$](../element/$$)
 
-[find-elements]: https://v7.webdriver.io/docs/api/webdriver/#findelements
-[how-to-use-selectors]: https://v7.webdriver.io/docs/selectors
+[find-elements]: https://webdriver.io/docs/api/webdriver/#findelements
+[how-to-use-selectors]: https://webdriver.io/docs/selectors

docs/commands/browser/$.mdx

@@ -41,7 +41,7 @@ await browser.$(selector);
 
 **index.html**
 
-```javascript
+```html
 <ul id="menu">
     <li>
         <a href="/">Home</a>
@@ -110,5 +110,5 @@ it("should use Androids DataMatcher or ViewMatcher selector", async ({ browser }
 -   [element.$](../element/$)
 -   [element.$$](../element/$$)
 
-[find-element]: https://v7.webdriver.io/docs/api/webdriver/#findelement
-[how-to-use-selectors]: https://v7.webdriver.io/docs/selectors
+[find-element]: https://webdriver.io/docs/api/webdriver/#findelement
+[how-to-use-selectors]: https://webdriver.io/docs/selectors