Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Current Selenium підтримує logging, network і script domains через bidirectional WebDriver APIs; різницю з Playwright коректніше описувати як integrated workflow та ergonomics.
Як працює проєктний білдер, ізоляція залежностей і впровадження нових інструментів →Сторона W3C WebDriver protocol, яка приймає HTTP command від local end, виконує browser automation operation і повертає HTTP response.
3. Selenium vs Playwright - яка різниця →Open-source ecosystem для UI automation, у якому client надсилає WebDriver-compatible commands до Appium server, а platform driver виконує їх на конкретній automation technology.
Типи мобільних застосунків та мобільна автоматизація →Глобальний timeout для кожної операції пошуку елемента в межах WebDriver session; значення за замовчуванням — 0.
1. Selenium початок, основи, фікстури →Фраза про історично складнішу роботу Selenium з console/network лишається корисним контекстом, але Selenium 4.46 документує WebDriver BiDi domains. Поточна різниця — інтегрованість trace/mocking workflow, а не абсолютна відсутність можливості.
Як працює проєктний білдер, ізоляція залежностей і впровадження нових інструментів →Поточний двосторонній protocol contract і статус Working Draft.
3. Selenium vs Playwright - яка різниця → Першоджерело ↗Selenium 4 використовує стандартизований W3C WebDriver protocol. Client binding надсилає HTTP-команди WebDriver endpoint, а browser-specific driver виконує їх у Chrome, Firefox, Edge, Safari чи іншому підтримуваному браузері. У старішому Selenium 3 застосовувався JSON Wire Protocol. У класичному Selenium flow перед click або input часто використовується explicit wait: client повторно перевіряє умову на кшталт visibility або clickability, а після її виконання надсилає окрему action command. Це створює більше round trips, особливо коли browser session віддалена. Сильна сторона Selenium — широка екосистема vendor drivers і remote providers. Якщо навіть невелика частка користувачів певного браузера означає сотні тисяч людей або браузер входить у договірну support matrix, таке покриття не можна відкидати лише через повільніший test run. У Python-проєкті технічно можна мати і Playwright, і Selenium tests під pytest: Playwright для основного functional suite, Selenium — для вузької cross-browser перевірки. Це виправдано лише реальною вимогою, бо два automation stacks подвоюють dependency, fixture та maintenance surface.
[Дивитися з 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 та процес, що виконує команди.
WebDriver BiDi додає двосторонні події й команди до WebDriver ecosystem: console/network events, більш оперативний browser state та можливості, для яких односпрямованого command-response API недостатньо. У відео технологія описується як така, що ще потребує узгодження версій Selenium, browser і driver та не має однакової зрілості у всіх language bindings. Фінальне порівняння: Playwright — менше ручних waits, багаті debugging artifacts і швидкий workflow для сучасних engines; Selenium — ширша browser/vendor compatibility, але більше інфраструктурних і synchronization витрат. Вибір робиться від support matrix, geography, потрібних protocols і вартості maintenance, а не від загальної популярності інструмента. Практичний default для курсу — Playwright. Selenium варто додавати лише тоді, коли конкретний browser або remote provider є перевіреною вимогою, яку Playwright suite не закриває.
Selenium розглядається не як одна функція для керування браузером, а як екосистема. Для Python-тестів ключовим є Selenium WebDriver; Selenium IDE дає змогу записати простий сценарій у браузері й згенерувати початковий код, а Grid стосується розподіленого запуску. Залежність додається через `pip install selenium` або `uv add selenium`, після чого середовище треба синхронізувати. Допоміжний `pytest-selenium` може спростити старт, але урок застерігає від прив’язки до слабо підтримуваної обгортки: базову Selenium fixture нескладно контролювати самостійно. `pytest` залишається test runner незалежно від браузерної бібліотеки. Тому Selenium- і Playwright-тести можуть певний час співіснувати в одному Python-проєкті під час поступової міграції; їх достатньо розвести по зрозумілих packages, не переписуючи весь набір одразу.
Стартовий тест напряму викликає `driver.find_element()`, `WebDriverWait(...).until(...)` і браузерні дії. Він придатний для перевірки ідеї, але змішує бізнес-сценарій із технікою Selenium, тому наступний крок — дати діям читабельні назви й рознести їх по Page Objects. Замість Playwright `Page` у конструктор Page Object передається Selenium WebDriver. Спільний `BasePage` зберігає driver і один раз ініціалізує стандартне очікування, щоб кожен клас сторінки не дублював timeout та polling configuration. Найпрактичніше представлення локатора — tuple на кшталт `(By.CSS_SELECTOR, "...")`. Воно зберігає і стратегію, і значення пошуку та напряму сумісне з locator-based expected conditions.
WebDriver перевіряє стани елементів через браузер і JavaScript. Надто частий polling може впливати на сторінку, яку тест вимірює, особливо якщо UI одночасно виконує важку клієнтську логіку. Тому частоту й timeout варто тримати розумними, а кількість UI-тестів — достатньою для критичних journeys, не максимальною. Іноді короткий `sleep` може бути прагматичним, якщо саме polling блокує потрібний browser work, але це виняток із виміряною причиною. За замовчуванням очікується конкретний спостережуваний стан через explicit wait. `StaleElementReferenceException` виникає, коли WebDriver зберіг internal ID елемента, а компонент перерендерився й старий DOM-вузол зник. Повторний виклик дії на старому `WebElement` уже не може спрацювати; потрібен повторний пошук за locator.
Після зміни залежностей запускається `uv sync`, а фактично встановлена версія звіряється з lock-файлом. Якщо імпорт не працює або підтягнулась неочікувана версія, спочатку треба перевірити синхронізацію середовища, а не змінювати тестовий код навмання. Створюється pytest fixture, яка ініціалізує `webdriver.Chrome()` і повертає driver тесту. Команди тесту надходять до browser driver, а він уже керує браузером. Аналогічно можна створювати Firefox, Edge або Safari driver, але для навчального сценарію достатньо Chrome. Сучасний Selenium Manager підбирає сумісний driver автоматично, тому за звичайного локального запуску не потрібно вручну завантажувати executable й прописувати шлях. Це спрощує fixture, але версії Selenium і браузера все одно мають залишатися відтворюваними в CI.
На базовому рівні потрібно розуміти 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 спричиняє взаємний вплив тестів.
Playwright має APIs для TypeScript/JavaScript, Python, Java і .NET. Найповніша інтеграція навколо власного runner, fixtures і reporting доступна у Playwright Test для TypeScript/JavaScript; у Python за orchestration зазвичай відповідає pytest та його plugins. Selenium також має офіційні language bindings, які перетворюють API-виклики на WebDriver commands. Окремі команди підтримують Selenium project і browser vendors, тому version compatibility та відмінності bindings залишаються частиною експлуатації. Обидва інструменти — великі multi-language ecosystems. Вибір мови впливає не лише на синтаксис, а й на доступність runner integrations, fixtures, reporters, tracing і швидкість появи нових можливостей.
`find_element()` є eager operation: команда одразу йде до WebDriver. Тому конструкція на кшталт `EC.visibility_of(driver.find_element(...))` не захищає від раннього `NoSuchElementException` — елемент уже намагалися знайти. Для елемента, який ще має з’явитися, використовується `EC.visibility_of_element_located((By.CSS_SELECTOR, selector))`. Condition отримує locator tuple і сам повторює пошук до успіху або timeout. Збереження `By.CSS_SELECTOR` у tuple також зменшує ризик переплутати тип локатора зі звичайним рядком. Різниця принципова: `is_displayed()` робить одне звернення до стану вже знайденого element ID, тоді як explicit wait повторює перевірку. Саме тому очікування треба прив’язувати до спостережуваного стану, а не просто додавати після будь-якого пошуку.