Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Page Objects передають locator tuple у BasePage, а кожна дія очікує власну перевірювану передумову.
click() працює лише з видимим і enabled елементом; type_text() — з видимим елементом.
2. Selenium організація PageObject's та Очікувань →Набір перевірок, які Playwright виконує перед locator action. Для click офіційний contract включає один match, visible, stable, receives events та enabled; timeout завершується TimeoutError.
3. Selenium vs Playwright - яка різниця →Набір перевірок Playwright перед дією. Для click це, зокрема, unique match, visible, stable, receives events та enabled.
Що має описувати isLoaded →Набір передумов, які Playwright перевіряє перед дією; для click() це зокрема visible, stable, receives-events та enabled state.
Створіть BasePage з wait-aware click() і type_text().
Збережіть локатори login page як tuple (By.CSS_SELECTOR, value).
Створіть предметний login() і перевірку success state.
Перерендерте один компонент у test page та переконайтеся, що дія повторно знаходить елемент за locator.
Тест читається через предметні Page Object methods і не використовує implicit wait або довгоживучі WebElement fields.
Зіставте class name з route, visible heading і product vocabulary.
Позначте methods, які маскують click як open, або змішують action і assertion.
Перейменуйте лише підтверджені невідповідності та запишіть два project rules у README.
Один короткий diff і два naming rules, які прибирають повторну суперечку на code review.
Playwright підтримує тривалий двосторонній канал із browser process і через browser-specific protocol передає команди click, fill, navigation та читання стану. Locator actions мають auto-waiting: перед дією Playwright перевіряє релевантні actionability conditions — наприклад, видимість, стабільність, можливість отримати events і editable state. Це дозволяє тесту формулювати намір «виконай click для цього locator», а orchestration layer бере на себе очікування готовності елемента в межах timeout. Auto-waiting не усуває потребу в assertion: після дії все одно треба перевірити очікуваний результат. Основні browser engines Playwright — Chromium, Firefox і WebKit. WebKit наближає поведінку Safari, але не є повною копією всіх Safari/macOS/iOS інтеграцій. Branded Chrome або Edge можуть запускатися як Chromium channels, проте повну browser matrix потрібно визначати з реальної product analytics і support policy.
У `BasePage` демонструються helpers для `open`, `refresh`, `find`, `find_all`, `click` і введення тексту. Перед дією helper чекає потрібний стан: visibility для введення або clickability для кліку. Так exception вказує на невиконану передумову, а не на випадковий наступний Selenium command. `send_keys()` вводить символи та може передавати спеціальні клавіші на кшталт Enter або Tab. На відміну від високорівневого fill у Playwright, він не гарантує очищення поля, тому `clear()` додається лише там, де сценарій справді починає з порожнього input. Не варто приховувати `clear()` у кожному введенні «про запас». Тест має явно задавати стартовий стан: іноді потрібен refresh, бо попередня невдала авторизація залишила validation message або інший стан, який просте очищення полів не скидає.
[Дивитися з 14:20](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=860s). Перед дією Playwright перевіряє її передумови. Для `locator.click()` це, зокрема, strict resolution до одного елемента, visibility, stability, здатність отримувати pointer events і enabled state. Якщо умови не виконуються до завершення timeout, action завершується помилкою замість випадкового кліку. Візуальний текст усередині button не завжди є правильним click target: event listener може бути на батьківському element, а вкладений `span` — лише оформленням. Через це семантичний locator на кшталт `getByRole('button', { name: ... })` часто стабільніший за пошук найглибшого text node. Велика активна область також краща для користувача й доступності. Вибір між `click()` і touch-oriented `tap()` має залежати від реального input mode та context configuration, а не лише від розміру viewport.
[Дивитися з 04:40](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=280s). Перехід у реалізацію `click()` показує виклик на кшталт `channel.send(...)`: назва команди та її parameters передаються нижчому шару. Далі досліджується ієрархія об’єктів: `Browser` створює `BrowserContext`, context містить `Page`, а page працює з frames і locators. Python- і Java-клієнти не реалізують browser automation незалежно від основного Playwright driver. Вони формують команди та обмінюються повідомленнями з driver process через transport. Саме тому package містить platform-specific executable, а public API різних мов лишається концептуально подібним.
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.
Інший recorder записує кроки login-сценарію та дозволяє обрати мову експорту. Згенерований приклад містить `goto`, `fill` і `click`, але не враховує дубльовані `#content-mobile` та `#content-desktop` блоки на сторінці Testomat.io. Через це локатор поля може знайти кілька вузлів і впасти у strict mode. Генератор бачить окрему дію, але не обов’язково розуміє контекст DOM або усталену архітектуру тестів. Код є чернеткою, а не готовим тестом.
[Дивитися з 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 та процес, що виконує команди.
Тест відкриває URL через `driver.get(config.url)`, знаходить поля email і password та вводить значення через `send_keys()`. Кнопка входу знаходиться за CSS-селектором з атрибутом `value`, після чого викликається `click()`. На відміну від Playwright locators, у Selenium базовими операціями є `find_element()` і `find_elements()`. Перша повертає перший знайдений елемент або кидає `NoSuchElementException`, друга — колекцію всіх збігів. Якщо селектор неунікальний, `find_element()` може мовчки обрати не той вузол, тому локатор треба перевіряти на реальній сторінці. Тип пошуку задається явно, наприклад `By.CSS_SELECTOR`. Якщо CSS-селектор усередині Python-рядка містить подвійні лапки, зовнішній рядок зручніше обгорнути одинарними, щоб не псувати синтаксис зайвим escaping.
Page Object збирає технічні дії у предметні кроки авторизації. Перед введенням він чекає готовність полів, після Sign in — очікуваний success state. Це робить тест коротшим, але не приховує важливі переходи стану. Для параметризованих негативних login cases кожен приклад має стартувати з контрольованого стану. Інакше message, що з’явився після першої спроби, може залишитися для наступної та дати false positive. Залежно від продукту потрібні нова сторінка, refresh або явне очищення стану. Повернення `self` з кожного `click()` чи `type_text()` дозволяє chaining, але урок ставиться до цього обережно: ланцюжок не повинен створювати операції, які предметно не мають сенсу. Читабельна окрема дія часто краща за універсальний fluent interface.
Функції Page Object називаються за дією тест-кейсу й починаються з дієслова; класи, файли, variables і constants позначають сутності або дані. Для однакових дій команда має обрати один словник — наприклад, послідовно використовувати `fill`, `click` і `select`, бажано близько до API обраного framework. Функцію, яка натискає кнопку, не варто називати `openPage`: окрема navigation-функція може відкривати URL напряму, обходячи довгий UI-шлях. Неминучі суперечки на code review краще завершити коротким naming convention у README, а не щоразу вирішувати те саме заново.