Conversation
✅ Successfully deployed static |
|
|
||
| - Создайте отдельные логические браузеры для ключевых комбинаций (Chrome, Safari, мобильный Chrome и т.д.) | ||
| - Запускайте регрессию раз в релиз или по расписанию | ||
| - Анализируйте видео и логи для редких сложно воспроизводимых багов |
shadowusr
left a comment
shadowusr
left a comment
There was a problem hiding this comment.
В целом получилась очень крутая статья на мой взгляд! 🔥
Ниже оставил ряд предложений по тому, что можно улучшить. Все они не критичные, но думаю еще немного улучшат содержание. Считаю, что почти готово к влитию, очень информативно, просто читается и с соблюдением всех гайдлайнов!
| } satisfies ConfigInput; | ||
| ``` | ||
|
|
||
| Ключ в `browsers` (`chrome`, `chrome-mobile`) — логическое **имя браузера**. Оно используется в CLI и в отчётах. Имя не ограничивает реальные настройки: в `desiredCapabilities` можно указать любой `browserName` и `browserVersion`. |
There was a problem hiding this comment.
Субъективно, конечно, но я бы не использовал выделение жирным здесь и далее. На мой взгляд, здесь выделение жирным не помогает восприятию информации. Ну и всякие LLMки очень любят сейчас сыпать жирным, не хочется, чтобы было похоже =)
|
|
||
| Ключ в `browsers` (`chrome`, `chrome-mobile`) — логическое **имя браузера**. Оно используется в CLI и в отчётах. Имя не ограничивает реальные настройки: в `desiredCapabilities` можно указать любой `browserName` и `browserVersion`. | ||
|
|
||
| **Версия браузера** задаётся в `desiredCapabilities.browserVersion`. Для локальных браузеров Testplane скачает нужную версию, если она поддерживается. Для Docker и облака версия должна совпадать с образом или настройками грида. |
There was a problem hiding this comment.
Тут чуточку корректнее было бы сказать, что для Docker и облака версия должна быть выбрана среди доступных там вариантов.
Образ может называться как угодно — selenoid/firefox:144.0-with-bidi. При этому версия браузера тут будет все еще 144.0, т.е. вообще не обязательно совпадение, важно, что зашито внутри образа.
Не критично
|
|
||
| **Версия браузера** задаётся в `desiredCapabilities.browserVersion`. Для локальных браузеров Testplane скачает нужную версию, если она поддерживается. Для Docker и облака версия должна совпадать с образом или настройками грида. | ||
|
|
||
| `headless: true` включает **запуск без графического интерфейса**. |
There was a problem hiding this comment.
Я бы наверное даже сделал это мини-секцией как про мобильную эмуляцию. И подчеркнул парочку моментов:
-
с точки зрения тестов, поведения браузера с headless true/false полностью одинаково, например, при запуске с headless=true все еще можно делать скриншоты и т.д. (были юзеры, которые путались и думали, что тогда это делать нельзя)
-
в окружениях, где нет UI, например, в CI джобах, нужно использовать headless=true, т.к. иначе будут ошибки вида
cannot open displayи т.д.
|
|
||
| ### Установка зависимостей | ||
|
|
||
| Скачать необходимые браузеры и драйверы: |
There was a problem hiding this comment.
я бы тут уточнил, что будут установлены все браузеры, указанные в конфиге, и для которых поддержана автоматическая установка, "необходимые" не очень понятно
|
|
||
| Есть два варианта: | ||
|
|
||
| **Через CLI-опцию `--local`:** |
| ./firefox/build.sh | ||
| ``` | ||
|
|
||
| Следить за появлением готовых свежих образов можно в [этом issue](https://github.com/gemini-testing/testplane/issues/1212). |
There was a problem hiding this comment.
Хотелось бы добавить 2 небольших раздела:
Как запустить образ одного браузера и прогнать в нём тесты
docker run -it --rm --privileged -p 4444:4444 -p 5900:5900 -e ENABLE_VNC='true' selenoid/chrome:128.0
Тут gridUrl нужен будет localhost:4444.
Как запустить selenoid с несколькими браузерами и прогнать в нём тесты:
Создаем конфиг browser.json (его можно спрятать под спойлер):
{
"chrome": {
"versions": {
"128.0": {
"image": "selenoid/chrome:128.0",
"path": "/",
"port": "4444",
"shmSize": 2147483648,
"tmpfs": {
"/tmp": "size=512m"
},
"volumes": [
"/tmp/.X11-unix:/tmp/.X11-unix"
]
},
},
"firefox": {
"versions": {
"145.0": {
"image": "selenoid/firefox:145.0",
"path": "/wd/hub",
"port": "4444",
"shmSize": 2147483648,
"tmpfs": {
"/tmp": "size=512m"
},
"volumes": [
"/tmp/.X11-unix:/tmp/.X11-unix"
]
}
}
}
}
Запускаем selenoid, указав этот конфиг (конфиг лежит в /home/selenoid-config/browsers.json, а в образ прорастет получается в /etc/selenoid/browsers.json):
docker run --rm -d --name selenoid -v /var/run/docker.sock:/var/run/docker.sock -v /home/selenoid-config:/etc/selenoid/:ro --network=host aerokube/selenoid:latest
Такая штука позволит запускать одновременно и chrome, и firefox в образах. И тут gridUrl будет localhost:4444/wd/hub.
Также можно оставить ссылку на доку selenoid для более подробной настройки.
|
|
||
| - Большой выбор браузеров и ОС | ||
| - Нет необходимости поднимать свою инфраструктуру | ||
| - Детальные логи и видео |
There was a problem hiding this comment.
Сюда тоже стоит вписать стабильность скриншотов
| - Зависимость от операционной системы: скриншоты могут различаться | ||
| - Нужен контроль за обновлением версий | ||
|
|
||
| Локальные браузеры подходят для разработки, быстрого прогона и отладки, но не идеальны для скриншотного тестирования между разными ОС. |
There was a problem hiding this comment.
У локальных браузеров пропали таблички поддержки автозагрузки и версий. Я думаю, это очень полезная инфа, которую стоит оставить.
|
|
||
| Облачные гриды удобны для регулярного кросс-браузерного и мобильного тестирования без поддержки собственной фермы браузеров. | ||
|
|
||
| ## Практические сценарии |
There was a problem hiding this comment.
Хм, я бы наверное эти практические сценарии схлопнул в краткое саммари по статье, т.к. эти практические сценарии не совсем практические ИМХО.
Что имею в виду. Описано 3 сценария. При этом все эти 3 сценария обычно есть в каждом проекте, всем надо разрабатываться, всем нужен CI и всем нужно кросс-браузерное тестирование.
Однако у каждого сценария дано свое отдельное решение. Складывается ощущение, что надо в итоге в любом проекте юзать и локальные браузеры, и докер, и грид — звучит сложно и неудобно.
Я бы рекомендовал выбирать что-то одно (либо бить тесты на паки, в каждом из которых выбирать что-то одно):
- Локальные браузеры — если не используются скриншотные тесты или для разработки/отладки, где удобна скорость
- Docker, если важна стабильность скриншотов и есть готовность работать с образами
- Облако — если важна стабильность скриншотов и важна масштабируемость на тысячах тестов для прогона с высокой параллельностью
Как правило, локальные браузеры являются самым простым и удобным вариантом, и двигаться нужно именно от него. Docker/Grid решают конкретные задачи (стабильные скрины и высокая параллельность на гриде), и нужно переходить на них, если локальные браузеры их не закрывают.
There was a problem hiding this comment.
Этот файл должен замещать вот эту статью: https://testplane.io/ru/docs/v8/basic-guides/managing-browsers/
Сейчас получилось 2 статьи на 1 тему, которые перекликаются.
Название я бы оставил лакончиное "Браузеры".
3 participants
No description provided.