Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Фраза про історично складнішу роботу Selenium з console/network лишається корисним контекстом, але Selenium 4.46 документує WebDriver BiDi domains. Поточна різниця — інтегрованість trace/mocking workflow, а не абсолютна відсутність можливості.
Як працює проєктний білдер, ізоляція залежностей і впровадження нових інструментів →Підтверджує research-уточнення цього уроку.
Як працює проєктний білдер, ізоляція залежностей і впровадження нових інструментів → Першоджерело ↗Уточнює Page Object, Page Component Object і допустиму readiness verification.
Неймінг та структура automation-проєкту → Першоджерело ↗Current Selenium підтримує logging, network і script domains через bidirectional WebDriver APIs; різницю з Playwright коректніше описувати як integrated workflow та ergonomics.
Як працює проєктний білдер, ізоляція залежностей і впровадження нових інструментів →Оберіть один проблемний Selenium-тест, сформулюйте вимірювану причину перенесення в Playwright, окремі CI-команди та умову, після якої міграцію варто розширювати.
Як працює проєктний білдер, ізоляція залежностей і впровадження нових інструментів →Selenium представлено як велику бібліотеку для керування браузером, до екосистеми якої належать WebDriver, Selenium Manager і Selenium IDE. У попередньому Selenide-тесті ініціалізація та закриття драйвера, очікування видимості й повторні спроби приховані за компактним API. У чистому Selenium ці кроки потрібно описувати явно. Для першого тесту створюється `ChromeDriver`, відкривається сторінка, а в кінці викликається `driver.quit()`. Якщо не закрити драйвер, запущений браузер і пов'язані процеси можуть залишитися в оперативній пам'яті.
[Дивитися з 34:20](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=2060s). Автор порівнює Playwright із Selenium CDP/BiDi APIs і досліджує documentation та source code наживо. Показано ризик version coupling: browser protocol modules, Selenium version і browser/driver version мають бути сумісними, інакше потрібна feature може бути недоступною. Network interception, request mocking і browser events у різних поколіннях Selenium APIs мали різний рівень готовності та різні способи підключення. Цей фрагмент варто сприймати як метод дослідження, а не стабільну шпаргалку API: перед реалізацією треба перевірити документацію саме встановленої версії dependency.
У Python-програмі Selenium розглядається, але основний інструмент — Playwright. Головна навичка автоматизатора не прив’язана до API конкретної бібліотеки: потрібно розуміти сторінку й API продукту, будувати тестовані сценарії та домовлятися з розробниками про стабільні селектори й testability. Playwright надає більше готових можливостей для console, network mocking, traces і компонентних перевірок. У Selenium подібні задачі історично були складнішими, хоча сучасні протоколи браузера розширили його можливості. TypeScript-версія Playwright має зручний `playwright.config`, але це не робить інші мови неповноцінними: конфігурацію, паралельність, sharding і репорти можна організувати іншими механізмами. Водночас async/Promise-модель TypeScript іноді додає складності, яка не пов’язана безпосередньо з тестовою задачею.
Проєкт розділяється на окремі пакети для Selenide і Selenium, після чого той самий сценарій переписується через `driver.findElement(...)`, `By.cssSelector(...)`, `sendKeys(...)` і `click()`. Для текстового локатора, якому немає прямого аналога `By.text`, використовується XPath. Механічна заміна Selenide-викликів допомагає швидко отримати початковий варіант, але залишає багатослівний код і не додає очікувань. Тому наступний крок — явно визначити, коли елемент готовий до пошуку, перевірки або дії.
Переписувати весь test suite з нуля зазвичай не потрібно. Коли старий тест зламався або нову задачу значно легше реалізувати новим засобом, її можна зробити на uv чи Playwright і залишити робочі старі тести на pip або Selenium. В одному репозиторії тимчасово можуть співіснувати: - pip і uv; - Maven і Gradle; - Selenium і Playwright; - pytest та інший test runner; - JUnit і TestNG. CI просто виконує окремі команди для відповідних наборів. Основний ризик — не саме співіснування, а конфлікти спільних транзитивних залежностей і додаткова вартість підтримки двох стеків. Найбезпечніший аргумент для міграції — конкретна користь на конкретному сценарії: швидше встановлення, простіша діагностика, потрібне мокання network або стабільніша робота з браузером. Після доказу підхід можна розширювати.
Чистий Selenium API придатний до роботи, але тест швидко стає багатослівним. На проєктах це часто приводить до самописних фреймворків, у яких різні Page Objects використовують різні реалізації кліку, пошуку й очікувань. Без одного спільного контракту така обгортка накопичує дублювання та ускладнює супровід. Принципи Selenium однакові для Java, Python, C#, Ruby та інших bindings: клієнт надсилає команди WebDriver, драйвер взаємодіє з браузером. Тому важливіше розуміти модель драйвера, waits, локатори й test runner, ніж запам'ятовувати лише синтаксис однієї мови.
Selenium виконує команди через WebDriver: тест звертається до драйвера HTTP-запитами, а драйвер керує браузером. Перевірки стану та explicit waits багаторазово опитують браузер, тому на віддаленому запуску через BrowserStack або іншу інфраструктуру network latency відчутно сповільнює тести й змушує змінювати polling interval. Playwright підтримує постійний двосторонній зв'язок із браузером і отримує результат виконаної команди через WebSocket. У відео це подається як причина меншої кількості мережевих затримок, кращої поведінки на remote execution і можливості працювати з Chromium, Firefox та WebKit через спільний API.
На базовому рівні потрібно розуміти primitives/value types, reference/object types, класи, об'єкти та принципи OOP. Із прикладних патернів найчастіше зустрічається Page Object; корисно впізнавати Singleton, Builder, Facade та інші рішення, але не впроваджувати їх без проблеми, яку вони реально спрощують. Page Factory виник навколо старих Selenium-підходів із lazy initialization елементів. Для сучасного Selenium або Playwright його не варто застосовувати за інерцією. У багатопоточному WebDriver framework кожен тест/worker повинен мати власний browser context або driver; спільний mutable driver спричиняє взаємний вплив тестів.
В уроці радять не змішувати implicit і explicit waits та для динамічних React/Angular-сторінок покладатися на explicit waits. Implicit wait очікує, доки елемент з'явиться в DOM під час `findElement`, але сама наявність вузла ще не означає, що він видимий, enabled або придатний до взаємодії. Після пошуку Selenium працює з ідентифікатором конкретного елемента. Якщо сторінка перерендерила вузол, старе посилання більше не відповідає поточному DOM і команда може завершитися `StaleElementReferenceException`. Explicit wait через `WebDriverWait.until(...)` і `ExpectedConditions` дозволяє чекати саме потрібного стану, наприклад видимості або очікуваного тексту.
[Дивитися з 09:10](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=550s). Для `click`, `dblclick`, `fill`, evaluate та інших actions у команду входять target locator, parent frame і options. Browser-side automation layer виконує пошук у правильному контексті та повертає результат або error. На прикладі Chromium автор пояснює роль Chrome DevTools Protocol і показує інструмент командного рядка, який також керує browser через локальний service. Для порівняння Selenium client зазвичай спілкується з browser-specific WebDriver через W3C WebDriver protocol, а driver уже координує browser. В обох випадках test code не клікає DOM напряму: між ним і browser є protocol та процес, що виконує команди.