Page Component Object
Object для дискретної частини page, яку можна вкладати в Page Object і повторно використовувати в кількох pages.
Неймінг та структура automation-проєкту →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Selenium Page object models
Уточнює Page Object, Page Component Object і допустиму readiness verification.
Неймінг та структура automation-проєкту → Першоджерело ↗Перевірити domain object наскрізно
Описати typed object з одним boundary field.
Створити валідний object у arrange.
Передати його у create action.
Звірити ті самі expected fields в API response і UI details.
Зберегти seed у failure output.
Один test відтворює data set і виявляє помилку mapping на конкретному checkpoint.
Створити file template для Page Object
Створіть custom file template з імпортом Page, класом, __init__, self.page і return self.
Використайте ${NAME} для назви створюваного класу або файла.
Створіть пробний Page Object і виправте всі syntax та inspection errors у самому шаблоні.
Новий Page Object створюється одним пунктом меню та не містить syntax або unresolved reference errors.
OpenAPI Schema Object
OpenAPI 3.1 Schema Object описує структуру payload через JSON Schema vocabulary. Список required визначає обов’язкові properties; оголошення property саме по собі не робить його обов’язковим.
Page Object Model
Design pattern, який відділяє test code від page-specific locators і operations; UI change зазвичай локалізується в одному object.
Неймінг та структура automation-проєкту →File template для Page Object
Page Object і Page Component мають повторювану основу: імпорти Playwright, клас, `__init__`, збереження `page`, базову перевірку завантаження та часто `return self`. Замість копіювання цієї «шапки» створено власний шаблон у `Settings → Editor → File and Code Templates`. У file template змінна `${NAME}` підставляє назву, яку вводять під час створення файлу. Після збереження в меню `New` з’являється окремий тип `Page Object`; вибір цього пункту створює клас з підготовленими імпортами й методами. Під час live coding шаблон кілька разів виправляється: додаються пропущені `self`, закривається дужка, коригуються відступи. Це нормальний цикл налаштування: створити пробний файл, дочекатися синтаксичних та інспекційних підказок IDE, виправити шаблон і повторити генерацію. Перевіряти потрібно саме згенерований файл, а не лише текст у вікні налаштувань. Оскільки поточні Page Object і Page Component мають однакову основу, одного file template достатньо. Окремі шаблони варто додавати лише тоді, коли їхня структура реально розійдеться.
Від сирого сценарію до Page Object
Стартовий тест напряму викликає `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.
Page Object і component boundaries
`LoginPage.login(email, password)` ховає locators і послідовність fill/click за дією користувача. Великий product page можна розкласти на логічні components, наприклад product card або related products, якщо вони мають власну поведінку. Page Object не повинен ставати контейнером усієї test logic.
Application object і поступова міграція
`send_keys()` використовується не лише для тексту: file input можна передати шлях до локального файлу, після чого браузер виконає upload. У такому спеціальному сценарії взаємодія з невидимим input може бути виправдана, тому generic helper не повинен безумовно вимагати visibility для кожної операції. Application object може один раз ініціалізувати всі Page Objects і дати тестам єдину точку доступу. Це прибирає повторну ініціалізацію з кожного тесту; обсяг статичних селекторів у пам’яті тут не є практичною проблемою. Той самий контейнер дозволяє поступово переводити Python-suite із Selenium на Playwright: старі Page Objects продовжують працювати, нові сценарії отримують Playwright implementation. Переписувати весь набір одразу не потрібно, особливо коли корисні API/database fixtures уже живуть у цьому pytest-проєкті.
Звідки брати назву Page Object
Першим джерелом назви сторінки є route: кореневий шлях підказує home page, а змістовний path — конкретний екран. Якщо це SPA або URL не змінюється, наступним джерелом стає видима назва сторінки: `h1`, `h2`, title чи інший семантичний заголовок. Коли framework генерує сторінку переважно з `div`, треба орієнтуватися на мову продукту та стабільні атрибути DOM. Мета — щоб назва в automation-коді відповідала тому, як екран уже називають користувачі й розробники.
`__init__` задає обов’язковий стан об’єкта
Через `__init__` клас отримує залежності й початковий стан, без яких його методи не мають сенсу. Наприклад, компонент приймає кореневий locator, а Page Object — Playwright `page`; наступні методи перевикористовують ці значення через `self`. У повсякденній мові `__init__` часто називають constructor. Технічно екземпляр створює `__new__`, а `__init__` ініціалізує вже створений об’єкт. Для звичайного Page Object достатньо реалізувати саме `__init__`.
Стабільні перевірки тарифу й перемикання проєкту
Tooltip із назвою тарифу з’являється після hover, тому тест спочатку знаходить стабільний label, виконує hover і лише потім перевіряє текст підписки. DOM/attribute breakpoints допомагають зрозуміти, який компонент створює анімацію. Повторювані елементи Enterprise і Free додаються в page object, а тест перевіряє стан до та після `select_company`. Це формує observable contract, на який можна спертися під час оптимізації авторизації.
Від простого UI-тесту до Page Objects, API та CI
[Дивитися з 05:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=330s). Suite ускладнюється вертикально: спочатку прямий UI-flow, потім reusable helpers, Page Objects, розширення object model, API preconditions і повторне використання authenticated state. Складніший сценарій може створити другу людину, зареєструвати її на event і перевірити participant list від імені admin. Пізніше ті самі tests мають запускатися в CI, де з’являться окремі environment-specific failures.
Що зберігає Playwright `page`
Playwright `Page` представляє окрему вкладку або сторінку в browser context. Переданий у Page Object екземпляр визначає, з яким саме браузерним контекстом працюватимуть locators, переходи й assertions. Збереження `page` як `self.page` прибирає потребу передавати його в кожен метод. Залежність залишається явною в initializer, а всі дії конкретного Page Object використовують одну й ту саму вкладку.
OOP, патерни й ізоляція browser state
На базовому рівні потрібно розуміти 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 спричиняє взаємний вплив тестів.