Skip to content

docs: browsers overview#118

Open
swordqueen wants to merge 10 commits intomasterfrom
users/kseniataranov/DOCORG-6611.browsers-overview
Open

docs: browsers overview#118
swordqueen wants to merge 10 commits intomasterfrom
users/kseniataranov/DOCORG-6611.browsers-overview

Conversation

@swordqueen
Copy link
Copy Markdown
Collaborator

No description provided.

@github-actions
Copy link
Copy Markdown

github-actions bot commented Mar 11, 2026

✅ Successfully deployed static


- Создайте отдельные логические браузеры для ключевых комбинаций (Chrome, Safari, мобильный Chrome и т.д.)
- Запускайте регрессию раз в релиз или по расписанию
- Анализируйте видео и логи для редких сложно воспроизводимых багов
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"сложновоспроизводимых" нужно слитно

Copy link
Copy Markdown

@janair77 janair77 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

комментарий

Copy link
Copy Markdown
Member

@shadowusr shadowusr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

В целом получилась очень крутая статья на мой взгляд! 🔥

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

} satisfies ConfigInput;
```

Ключ в `browsers` (`chrome`, `chrome-mobile`) — логическое **имя браузера**. Оно используется в CLI и в отчётах. Имя не ограничивает реальные настройки: в `desiredCapabilities` можно указать любой `browserName` и `browserVersion`.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Субъективно, конечно, но я бы не использовал выделение жирным здесь и далее. На мой взгляд, здесь выделение жирным не помогает восприятию информации. Ну и всякие LLMки очень любят сейчас сыпать жирным, не хочется, чтобы было похоже =)


Ключ в `browsers` (`chrome`, `chrome-mobile`) — логическое **имя браузера**. Оно используется в CLI и в отчётах. Имя не ограничивает реальные настройки: в `desiredCapabilities` можно указать любой `browserName` и `browserVersion`.

**Версия браузера** задаётся в `desiredCapabilities.browserVersion`. Для локальных браузеров Testplane скачает нужную версию, если она поддерживается. Для Docker и облака версия должна совпадать с образом или настройками грида.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Образ может называться как угодно — selenoid/firefox:144.0-with-bidi. При этому версия браузера тут будет все еще 144.0, т.е. вообще не обязательно совпадение, важно, что зашито внутри образа.

Не критично


**Версия браузера** задаётся в `desiredCapabilities.browserVersion`. Для локальных браузеров Testplane скачает нужную версию, если она поддерживается. Для Docker и облака версия должна совпадать с образом или настройками грида.

`headless: true` включает **запуск без графического интерфейса**.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Я бы наверное даже сделал это мини-секцией как про мобильную эмуляцию. И подчеркнул парочку моментов:

  • с точки зрения тестов, поведения браузера с headless true/false полностью одинаково, например, при запуске с headless=true все еще можно делать скриншоты и т.д. (были юзеры, которые путались и думали, что тогда это делать нельзя)

  • в окружениях, где нет UI, например, в CI джобах, нужно использовать headless=true, т.к. иначе будут ошибки вида cannot open display и т.д.


### Установка зависимостей

Скачать необходимые браузеры и драйверы:
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

я бы тут уточнил, что будут установлены все браузеры, указанные в конфиге, и для которых поддержана автоматическая установка, "необходимые" не очень понятно


Есть два варианта:

**Через CLI-опцию `--local`:**
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

тоже думаю можно без жирного

./firefox/build.sh
```

Следить за появлением готовых свежих образов можно в [этом issue](https://github.com/gemini-testing/testplane/issues/1212).
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Хотелось бы добавить 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 для более подробной настройки.


- Большой выбор браузеров и ОС
- Нет необходимости поднимать свою инфраструктуру
- Детальные логи и видео
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Сюда тоже стоит вписать стабильность скриншотов

- Зависимость от операционной системы: скриншоты могут различаться
- Нужен контроль за обновлением версий

Локальные браузеры подходят для разработки, быстрого прогона и отладки, но не идеальны для скриншотного тестирования между разными ОС.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


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

## Практические сценарии
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Хм, я бы наверное эти практические сценарии схлопнул в краткое саммари по статье, т.к. эти практические сценарии не совсем практические ИМХО.

Что имею в виду. Описано 3 сценария. При этом все эти 3 сценария обычно есть в каждом проекте, всем надо разрабатываться, всем нужен CI и всем нужно кросс-браузерное тестирование.

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

Я бы рекомендовал выбирать что-то одно (либо бить тесты на паки, в каждом из которых выбирать что-то одно):

  • Локальные браузеры — если не используются скриншотные тесты или для разработки/отладки, где удобна скорость
  • Docker, если важна стабильность скриншотов и есть готовность работать с образами
  • Облако — если важна стабильность скриншотов и важна масштабируемость на тысячах тестов для прогона с высокой параллельностью

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Этот файл должен замещать вот эту статью: https://testplane.io/ru/docs/v8/basic-guides/managing-browsers/

Сейчас получилось 2 статьи на 1 тему, которые перекликаются.

Название я бы оставил лакончиное "Браузеры".

Copy link
Copy Markdown
Member

@shadowusr shadowusr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Статья получилась супер. Можно поправить несколько минорных моментов ниже и вливать. Мне всё понравилось. Четко, кратко, понятно и при этом исчерпывающе.

⚠️ Важно не забыть синкнуть изменения в английскую версию!


### Мобильная эмуляция

Для Chrome используйте `goog:chromeOptions.mobileEmulation`:
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Давай оставим ссылку на документацию, где можно посмотреть остальные поддерживаемые настройки: https://developer.chrome.com/docs/chromedriver/mobile-emulation

}
```

Для Firefox можно эмулировать мобильный user-agent через `moz:firefoxOptions`:
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Давай еще подкинем в пример как задать pixel ratio, window size

Image

Для Chrome используйте `goog:chromeOptions.mobileEmulation`:

```ts
"goog:chromeOptions": {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Еще небольшой нюанс по сниппетам с кодом в целом.

У нас в проекте работает prettier, который умеет форматировать код внутри таких сниппетов, поддерживая единый стиль отступов, кавычек, запятых на конце и т.д.

Поэтому важно, чтобы если сниппет обозначен как ts, в нем был валидный код на TS. Сейчас это не так — и такой сниппет не будет форматироваться. Его можно поправить так, например:

const desiredCapabilities = {
  "goog:chromeOptions": {
      mobileEmulation: {
        deviceName: "iPhone 12 Pro",
    }
  }
};

либо как json, но главное, чтобы объявленный язык сниппета совпадал с реальностью.

Это не прям критичный момент, но nice to have.

export default {
browsers: {
chrome: {
gridUrl: "http://localhost:4444/wd/hub",
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

мелочь, но при запуске образа chrome без selenoid gridUrl будет http://localhost:4444 — без wd/hub на конце

},
},
headless: true,
},
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

тут чутка рассинхрон мысленный с browsers.json. там указано два браузера, chrome и firefox, тут тоже 2, но внезапно это chrome и chrome-mobile, а firefox мы тут не юзаем. Зачем настраивали его тогда? =)

Да, я понимаю, что это потому что в других секциях мы этот пример юзаем, и это хорошо, как я и просил!

Но можно тогда или словами просто сказать "нам еще тут firefox доступен благодаря selenoid конфигу". Короче как-то упомянуть этот момент.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants