Відеобібліотека

Знайди точне пояснення

Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.

Python мануфактураJavaDesign Patterns для автоматизаторів

Терміни, нюанси та джерела

Що змінилося після запису · 5:00

Selenium Manager

У відео Selenium Manager описано як автоматичний механізм, через який webdriver.Chrome() отримує потрібний driver без ручного шляху.

Станом на 2026-07-31 офіційна документація описує Selenium Manager як fallback, коли driver не передано або не знайдено. Він постачається з bindings від Selenium 4.6, підтримує керування браузерами від 4.11 і досі позначений як Beta.

Selenium 4.6 для bundled driver management; Selenium 4.11 для automated browser management

1. Selenium початок, основи, фікстури →

Що змінилося після запису · 19:47

Selenium уже має network і console APIs

Фраза про історично складнішу роботу Selenium з console/network лишається корисним контекстом, але Selenium 4.46 документує WebDriver BiDi domains. Поточна різниця — інтегрованість trace/mocking workflow, а не абсолютна відсутність можливості.

Як працює проєктний білдер, ізоляція залежностей і впровадження нових інструментів →

Термін · 5:00

Selenium Manager

Вбудований CLI-інструмент Selenium, який bindings використовують як fallback для автоматизованого керування browser drivers і, за потреби, браузерами.

1. Selenium початок, основи, фікстури →

Що змінилося після запису · 0:00

Branded Chrome і Edge доступні як Chromium channels

Урок описує пряме Playwright coverage через Chromium, Firefox і WebKit та відносить Edge/Opera до ширшої Selenium matrix.

Поточна Playwright Python documentation перелічує Google Chrome і Microsoft Edge channels. Це branded Chromium channels, а не додаткові browser engines. Patched Firefox не є stock branded Firefox, а Playwright WebKit не є branded Safari.

3. Selenium vs Playwright - яка різниця →

Python мануфактура · Програма курсу · 0:00–5:00

Selenium як набір інструментів і залежність проєкту

Selenium розглядається не як одна функція для керування браузером, а як екосистема. Для Python-тестів ключовим є Selenium WebDriver; Selenium IDE дає змогу записати простий сценарій у браузері й згенерувати початковий код, а Grid стосується розподіленого запуску. Залежність додається через `pip install selenium` або `uv add selenium`, після чого середовище треба синхронізувати. Допоміжний `pytest-selenium` може спростити старт, але урок застерігає від прив’язки до слабо підтримуваної обгортки: базову Selenium fixture нескладно контролювати самостійно. `pytest` залишається test runner незалежно від браузерної бібліотеки. Тому Selenium- і Playwright-тести можуть певний час співіснувати в одному Python-проєкті під час поступової міграції; їх достатньо розвести по зрозумілих packages, не переписуючи весь набір одразу.

1. Selenium початок, основи, фікстури →

Python мануфактура · Програма курсу · 6:00–14:00

Selenium WebDriver, explicit waits і ширша matrix

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.

3. Selenium vs Playwright - яка різниця →

Python мануфактура · Сесії: AMA та PMP · 34:20–40:00

Selenium CDP/BiDi та version coupling

[Дивитися з 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.

Як Playwright взаємодіє з браузером через протокол →

Python мануфактура · Сесії: AMA та PMP · 19:47–23:40

Selenium, Playwright і реальна цінність тесту

У Python-програмі Selenium розглядається, але основний інструмент — Playwright. Головна навичка автоматизатора не прив’язана до API конкретної бібліотеки: потрібно розуміти сторінку й API продукту, будувати тестовані сценарії та домовлятися з розробниками про стабільні селектори й testability. Playwright надає більше готових можливостей для console, network mocking, traces і компонентних перевірок. У Selenium подібні задачі історично були складнішими, хоча сучасні протоколи браузера розширили його можливості. TypeScript-версія Playwright має зручний `playwright.config`, але це не робить інші мови неповноцінними: конфігурацію, паралельність, sharding і репорти можна організувати іншими механізмами. Водночас async/Promise-модель TypeScript іноді додає складності, яка не пов’язана безпосередньо з тестовою задачею.

Як працює проєктний білдер, ізоляція залежностей і впровадження нових інструментів →

Python мануфактура · Програма курсу · 0:00–5:35

Стратегія поступової міграції legacy-тестів

Повне одночасне переписування Selenium-проєкту на Playwright створює надто великий ризик. Практичний порядок інший: спочатку переносити тести, які вже падають або є flaky, потім — короткі ізольовані сценарії, а далі рухатися функціональними зрізами. Старі й нові інструменти можуть тимчасово співіснувати в одному репозиторії. Окремі pytest suites і CI-команди дозволяють запускати Selenium та Playwright незалежно, тому міграцію можна виконувати без зупинки розвитку наявного набору тестів.

1. Фіксаємо назви файлів, рефакторинг та оптимізація під Python, підключаємо Ruff та uv →

Python мануфактура · Програма курсу · 5:00–10:00

Синхронізація середовища та pytest fixture для Chrome

Після зміни залежностей запускається `uv sync`, а фактично встановлена версія звіряється з lock-файлом. Якщо імпорт не працює або підтягнулась неочікувана версія, спочатку треба перевірити синхронізацію середовища, а не змінювати тестовий код навмання. Створюється pytest fixture, яка ініціалізує `webdriver.Chrome()` і повертає driver тесту. Команди тесту надходять до browser driver, а він уже керує браузером. Аналогічно можна створювати Firefox, Edge або Safari driver, але для навчального сценарію достатньо Chrome. Сучасний Selenium Manager підбирає сумісний driver автоматично, тому за звичайного локального запуску не потрібно вручну завантажувати executable й прописувати шлях. Це спрощує fixture, але версії Selenium і браузера все одно мають залишатися відтворюваними в CI.

1. Selenium початок, основи, фікстури →

Python мануфактура · Сесії: AMA та PMP · 8:38–12:10

Поступове впровадження нового інструмента

Переписувати весь test suite з нуля зазвичай не потрібно. Коли старий тест зламався або нову задачу значно легше реалізувати новим засобом, її можна зробити на uv чи Playwright і залишити робочі старі тести на pip або Selenium. В одному репозиторії тимчасово можуть співіснувати: - pip і uv; - Maven і Gradle; - Selenium і Playwright; - pytest та інший test runner; - JUnit і TestNG. CI просто виконує окремі команди для відповідних наборів. Основний ризик — не саме співіснування, а конфлікти спільних транзитивних залежностей і додаткова вартість підтримки двох стеків. Найбезпечніший аргумент для міграції — конкретна користь на конкретному сценарії: швидше встановлення, простіша діагностика, потрібне мокання network або стабільніша робота з браузером. Після доказу підхід можна розширювати.

Як працює проєктний білдер, ізоляція залежностей і впровадження нових інструментів →

Python мануфактура · Програма курсу · 14:00–21:00

Local і remote execution

Локально Selenium client, driver і browser часто знаходяться на одній машині, тому додаткові HTTP round trips майже непомітні. У remote topology команди можуть пройти від CI runner до Selenium Server/Grid, далі до remote node або cloud browser і назад. Polling explicit waits множить network latency на кількість перевірок. Географія також впливає на system behavior: CI runner, browser node і application backend у різних регіонах дають інший latency profile, ніж локальна машина. Тому green local run не доводить, що timeout достатній для Grid/BrowserStack. Remote suite треба перевірити до merge, а browser nodes за можливості розміщувати ближче до application environment. У Playwright очікування й action orchestration потребують менше client-side polling round trips, тому modern UI suite зазвичай працює швидше й стабільніше. Але запити самої сторінки до backend однаково залежать від мережі: Playwright не прибирає latency тестованої системи.

3. Selenium vs Playwright - яка різниця →

Python мануфактура · Програма курсу · 21:00–25:00

Мовні реалізації, runner і bindings

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 і швидкість появи нових можливостей.

3. Selenium vs Playwright - яка різниця →

Python мануфактура · Програма курсу · 25:00–29:46

WebDriver BiDi та критерії вибору

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 не закриває.

3. Selenium vs Playwright - яка різниця →
Запитати в чаті про «selenium» →