Page Object: від класики до компонентів

Що таке Page Object і яку проблему він розв'язує?

Page Object (POM) — це клас-фасад, який тримає в собі все знання про один екран: як знайти на ньому елементи і які дії над ним можливі. Розв'язує він дві споріднені біди автоматизації без шару абстракції: дублювання кроків і крихкість тестів. Дублювання виникає, коли сценарій входу чи будь-яка рутина розписані прямо в десятках тестів; крихкість — коли селектор #login-btn протікає в кожен тест, що його згадує, і косметична зміна верстки червонить сюїту без жодного реального бага. Об'єкт сторінки розводить рівні: тест говорить мовою домену (loginPage.login(user)), а не мовою DOM, і локатор живе рівно в одному місці. Сильна відповідь одразу називає ключову цінність — єдине джерело істини для локатора: перейменували кнопку, правиш один рядок в одному класі, і всі тести лагодяться самі.

З яких частин складається класичний page object у мінімальній формі?

Рівно з двох: локатори (де що лежить на екрані) і дії (що з цим можна робити). Локатори описують спосіб пошуку елементів — поля, кнопки, банери; дії — методи, які виконують над ними осмислені операції. Більше в мінімальному page object нічого не потрібно: ні станів, ні бізнес-логіки продукту, ні тестових даних. Усе, що складніше, — це вже або компоненти, які клас у себе включає, або відповідальність, яку варто винести назовні. Розуміння цієї двоскладовості рятує від роздування класу: щойно з'являється спокуса запхати сюди ще й перевірки чи побудову фікстур, це сигнал, що межа патерну порушується.

Чому локатори всередині page object роблять приватними?

Щоб деталь реалізації UI не витекла назад у тести. Уся суть патерну — сховати «як саме дістатися до елемента» за методами «що робимо», тому якщо тест може дотягнутися до самого локатора, інкапсуляція фіктивна. Публічний локатор означає, що завтра хтось напише в тесті page.locator(loginPage.emailField).fill(...), і селектор знову розповзеться по сюїту. Приватність фізично забороняє цей шлях: єдиний спосіб взаємодіяти зі сторінкою — через її методи. Це той самий інкапсуляційний принцип ООП, лише прикладений до тестового коду.

Чому метод clickLoginButton() — поганий, а login() — добрий?

Бо метод page object має описувати намір користувача, а не механіку кліків. clickLoginButton(), enterTextInEmailField() — це той самий імперативний код, лише перенесений в інший файл: абстракція нульова, бо тест усе одно мислить кнопками й полями, а не діями домену. login(user) ховає послідовність (заповнити email, заповнити пароль, натиснути кнопку) за одним осмисленим викликом, і коли форму перероблять — додадуть CAPTCHA чи розіб'ють на два кроки — тести не зміняться, бо намір «увійти» лишився тим самим. Практичний критерій: якщо назва методу читається як частина інструкції з DOM, а не як дія користувача, абстракцію не витягнуто.

Чому за нашою конвенцією page object не віддає назовні Locator чи WebElement?

Бо це та сама протікаюча абстракція, лише замаскована. Одразу застереження: джерельної опори в цього правила немає — офіційний приклад Playwright тримає локатори публічними й перевіряє їх прямо в тесті, тож нижче наша домовленість, а не галузева норма. Формально локатор оголошений усередині класу, але якщо метод повертає його назовні і тест сам робить .click(), деталь реалізації знову опинилась у тесті — і сенс POM втрачено. Правильно page object повертає дані або стан: getErrorText(): Promise<string>, isSubmitEnabled(): Promise<boolean>, а всі взаємодії тримає в собі. Виняток на практиці роблять для web-first assertions Playwright: тонкий геттер може віддати Locator виключно щоб тест зробив expect(locator).toHaveText(...), але це усвідомлений компроміс під ретрайну перевірку, а не дозвіл клікати елементи ззовні.

Чому в Playwright локатори безпечно оголошувати в конструкторі, а в класичному Selenium — ні?

Через різну природу того, що ти зберігаєш. Locator у Playwright лінивий: він не шукає елемент у момент створення, а лише запам'ятовує рецепт пошуку і виконує його щоразу під час дії. Тому оголосити всі локатори в конструкторі можна ще до того, як сторінка завантажилась, — жодної шкоди. У класичному Selenium @FindBy/PageFactory дають WebElement — посилання на конкретний вже знайдений вузол DOM; коли сторінка перемальовується, це посилання «протухає», і будь-яка дія над ним кидає StaleElementReferenceException. Playwright цієї пастки не має за побудовою, бо перешукує елемент під кожну взаємодію. Розуміння цієї різниці пояснює, чому старі гайди наполягали на PageFactory-магії, а сучасні — просто на полях-локаторах.

Чи має page object містити асерти? Розкрий холівар.

Правильна відповідь тут — «залежить», але з поясненням, від чого саме: три канонічні для теми джерела дають три різні норми, і різняться вони модальністю — силою, з якою кожне говорить. Мартін Фаулер — власна позиція автора: він наводить аргументи обох сторін і формулює висновок від першої особи («I favor having no assertions in page objects»), тобто це перевага, а не припис; робота об'єкта — надати доступ до стану, а рішення «що з цього правильне» належить тесту, і так об'єкт лишається перевикористовним і в позитивному, і в негативному сценарії. Виняток він теж називає за себе — перевірка інваріантів (чи це взагалі та сторінка і чи вона завантажилась) доречна. Selenium — нормативний припис: «Page objects themselves should never make verifications or assertions», і тут же рівно один виняток, теж обов'язковий (can, and should) — перевірити, що сторінка й критичні елементи завантажилися, причому під час створення об'єкта. Playwright — практика в офіційному прикладі: припису немає взагалі, зате приклад у доці імпортує expect у файл page object, ставить перевірку всередину методу і тримає локатори публічними, щоб тест перевіряв їх напряму. Саме на цю практику спирається контраргумент практиків: винести геть усі асерти означає дублювати прості перевірки в багатьох тестах, тому дрібні assert-методи, що інкапсулюють складне очікування, лишають усередині. Окремо стоїть Cypress: його дока називає спільні page object'и антипатерном і радить ізольовані специфікації, програмний логін і керування станом застосунку — це вже не про місце асерту, а про сам шаринг об'єкта. Наше робоче правило поверх усіх трьох (це конвенція, не цитата): не змішуй у одному методі дію і перевірку її результату — інакше метод не перевикористаєш там, де очікується протилежне. Відповідь «ні, ніколи» слабка не через категоричність, а тому, що приписує одному джерелу силу, якої воно не має, і мовчить про два інші.

Як web-first assertions Playwright впливають на цей холівар?

Вони роблять його менш болючим. Оскільки expect(locator).toHaveText(...) сам чекає й ретраїть, зникає головна причина ховати ручні очікування всередині page object — раніше туди тягли waitFor-обгортки, бо без них перевірка флакувала. Тепер можна віддати Locator через тонкий геттер лише під асерт і перевіряти прямо в тесті без сирого очікування, лишивши бізнес-рішення там, де йому місце. Тобто інструмент частково знімає компроміс, через який колись і сперечалися табори. Незмінним лишається базове правило про нерозділюваність дії та перевірки в одному методі — це вже не про інструмент, а про перевикористовність.

Що таке fluent-інтерфейс і чому класичний варіант погано лягає на Playwright?

Fluent-інтерфейс — це стиль, коли методи повертають об'єкт, щоб виклики зчіплювались у ланцюжок, який читається майже як речення: loginPage.typeEmail(...).typePassword(...).submit(). Щоб так працювало, кожен метод повертає this, і в синхронному Selenium-світі на Java це популярний прийом. У Playwright він майже не приживається, бо методи асинхронні: вони повертають Promise, тож чистого синхронного зчеплення не буде — довелося б повертати Promise<this> і городити await (await po.typeEmail()).typePassword(), що читається гірше за звичайні окремі await. Тобто проблема не в ідеї, а в тому, що вона конфліктує з асинхронною моделлю мови. Корисніша форма fluent тут інша — повертати не this, а наступний page object з методу навігації.

Навіщо метод навігації повертає наступний page object?

Щоб закодувати в типах дозволені переходи між екранами. Коли login() повертає DashboardPage, компілятор фізично не дасть викликати метод дашборда до того, як ти реально «увійшов» — маршрут користувача перетворюється на ланцюжок, який перевіряється статично. У тесті це читається природно: const dashboard = await new LoginPage(page).login(user) веде прямо до наступного стану. Мінус — жорсткіша зчепленість: page object логіну тепер знає про існування дашборда. Тому повертати наступну сторінку варто лише там, де перехід однозначний, і не варто, коли метод може вести в кілька різних станів — інакше тип збреше про реальність.

Чим компонентний об'єкт відрізняється від page object і навіщо він потрібен?

Це той самий патерн інкапсуляції, але одиниця — не цілий екран, а повторюваний шматок UI: хедер, футер, таблиця, модалка, віджет фільтрів. Правило «одна сторінка — один клас» ламається об сучасний веб, де ці блоки живуть на десятках екранів; без компонентів локатори хедера дублюються в кожному page object, тобто дублювання просто піднімається на рівень вище. Компонентний об'єкт описує блок один раз, а сторінки його включають. Ключовий нюанс реалізації — компонент приймає свій кореневий Locator і всі пошуки веде від нього, а не по всій сторінці, тому один клас TableComponent обслуговує і таблицю замовлень, і таблицю користувачів: треба лише передати інший корінь. Це і є «від класики до компонентів» — з поправкою, що компонентність не еволюція патерна: першоджерело від початку радить будувати об'єкти на значущі елементи сторінки, а не на кожну сторінку, і навіть визнає назву «page» оманливою. «Одна сторінка — один клас» додала практика.

Чому скоуп пошуку всередині компонента треба звужувати до його кореня?

Бо інакше два однакові компоненти на одному екрані конфліктуватимуть. Якщо TableComponent шукає рядок через page.getByRole('row'), а на сторінці дві таблиці, локатор поверне рядки з обох і перевірка стане неоднозначною або впаде на strict-mode. Коли ж компонент веде пошук від переданого кореня (this.root.getByRole('row')), він фізично не бачить нічого поза своїм піддеревом. Саме скоупінг робить компонент по-справжньому перевикористовним: клас не прив'язаний до жодного конкретного місця на сторінці, а працює з будь-яким коренем, який йому дали. Без цього компонентний підхід розсипається на першому ж екрані з двома схожими блоками.

Композиція чи успадкування для спільних елементів, і чому?

Композиція. Спільний хедер чи таблицю page object має містити (has-a), а не успадковувати (is-a): він тримає компонент як поле, а не тягне його вниз ланцюжком спадку. Глибокі ієрархії на кшталт BasePage → AuthorizedPage → AdminPage → AdminUsersPage крихкі, бо зміна в базовому класі непередбачувано зачіпає всіх нащадків, а перевикористати шматок логіки з середини такого ланцюга майже неможливо. Композиція ж дозволяє зібрати сторінку з незалежних блоків і перевикористати кожен окремо, де він реально потрібен. Тому на питання «як прибрати дублювання спільних елементів» очікувана відповідь — винести їх у компонент і включати, а не будувати вертикаль успадкування.

Що таке god object у контексті POM і як його уникнути?

god object — усталений антипатерн ООП: обʼєкт із посиланнями на велику кількість різних типів і/або надто багатьма незвʼязаними методами, класифікований як «an example of an anti-pattern and a code smell». Порогів у рядках означення не дає, тож числа далі — ілюстрація. У POM це page object, який розрісся до класу на півтори тисячі рядків і знає про все одразу — хедер, футер, три модалки, таблицю й половину бізнес-логіки. Симптом упізнаваний: будь-яка зміна UI чіпає цей файл, і кілька інженерів постійно ловлять у ньому конфлікти при мерджі. Причина — порушений принцип єдиної відповідальності: один клас відповідає за десяток незв'язних речей. Лікування — розбити його на компоненти, де кожен клас тримає рівно один зв'язний шматок екрана. Це прямо перегукується з переходом «від сторінок до компонентів»: god object майже завжди означає, що повторювані блоки не винесли в окремі об'єкти.

Page Object — це патерн лише про UI?

Ні, і це найглибша частина відповіді на співбесіді. Page Object — окремий випадок ширшого принципу: сховати деталі протоколу за фасадом мовою домену. Прибери браузер — і той самий підхід дає API-клієнт: клас, що інкапсулює знання про ендпоінти, де UsersApi.create() — це рівно те саме, що LoginPage.login(), лише ховає не селектор, а URL і метод HTTP. Тест, який дьорбає ендпоінти напряму, страждає від тих самих бід, що й тест із розсипаними локаторами: форма запиту дублюється, зміна контракту ламає десятки місць. Такий клієнт ще й незамінний для швидкої підготовки стану через API замість повільного проходу по UI. Хто бачить цей спільний корінь, розуміє і критику POM — що він змішує в одному класі кілька ролей (локатори, дії, іноді перевірки), які патерн Screenplay розводить окремо.

Три кейси, які показують POM у роботі: як рефакторинг у page object прибирає крихкість, як один компонент обслуговує дві однакові таблиці на екрані завдяки скоупінгу, і як той самий фасад працює без браузера — в API-клієнті для підготовки стану. Скрізь — що саме дивитися і чому.

Кейс 1. Рефакторинг: із розсипаних локаторів у фасад

Стартова точка — типовий тест без жодної абстракції над сторінкою. Логін розписаний прямо в кроках, а селектори вшиті в перевірку.

test('порожній кошик показує заглушку', async ({ page }) => {
  await page.goto('/login');
  await page.locator('#email').fill('qa@example.com');
  await page.locator('#password').fill('secret');
  await page.locator('#login-btn').click();
  await page.goto('/cart');
  await expect(page.locator('.cart-empty')).toBeVisible();
});

Тепер уяви ще двадцять тестів із тим самим початком. Розробники перейменували #login-btn на #signin-btn — і червоніє двадцять один тест, хоча продукт працює. Виносимо знання про екран у клас:

export class LoginPage {
  private readonly email: Locator;
  private readonly password: Locator;
  private readonly submit: Locator;

  constructor(private readonly page: Page) {
    this.email = page.getByLabel('Email');
    this.password = page.getByLabel('Пароль');
    this.submit = page.getByRole('button', { name: 'Увійти' });
  }

  async open(): Promise<void> {
    await this.page.goto('/login');
  }

  async login(user: { email: string; password: string }): Promise<void> {
    await this.email.fill(user.email);
    await this.password.fill(user.password);
    await this.submit.click();
  }
}

Тест після рефакторингу говорить мовою наміру, а не DOM:

test('порожній кошик показує заглушку', async ({ page }) => {
  const login = new LoginPage(page);
  await login.open();
  await login.login({ email: 'qa@example.com', password: 'secret' });
  await expect(page.getByTestId('cart-empty')).toBeVisible();
});

Що дивитися і чому:

• Селектор кнопки тепер живе рівно в одному місці. Те саме перейменування правиться одним рядком у класі — двадцять один тест лагодиться сам. Це і є єдине джерело істини, заради якого існує патерн.
• Локатори private — наша конвенція. Тест фізично не може дотягнутися до submit і клікнути його напряму, тож деталь реалізації не витікає назад у сюїту. Офіційний приклад Playwright робить інакше — тримає локатори публічними readonly, — тож це домовленість команди, а не вимога джерела.
• login() описує намір, а не кроки. Додадуть у форму CAPTCHA чи розіб'ють її на два екрани — сигнатура методу не зміниться, бо намір «увійти» лишився. Метод clickLoginButton() тут був би тим самим імперативним кодом, лише в іншому файлі.
• Локатори в конструкторі безпечні. getByLabel повертає лінивий Locator — рецепт пошуку, а не знайдений вузол; він виконається під час fill, а не в момент створення. У Selenium аналогічний @FindBy дав би WebElement, який протух би при перемальовуванні сторінки з StaleElementReferenceException.

Кейс 2. Компонент, який обслуговує дві таблиці на одному екрані

На дашборді дві однакові таблиці — активні замовлення і архів. Спокуса написати два майже ідентичні page object або дублювати локатори рядків. Замість цього виносимо таблицю в компонент, який веде пошук від свого кореня.

export class TableComponent {
  constructor(private readonly root: Locator) {}

  row(text: string): Locator {
    return this.root.getByRole('row').filter({ hasText: text });
  }

  async sortBy(column: string): Promise<void> {
    await this.root.getByRole('columnheader', { name: column }).click();
  }

  async rowCount(): Promise<number> {
    return this.root.getByRole('row').count();
  }
}

export class DashboardPage {
  readonly active: TableComponent;
  readonly archive: TableComponent;

  constructor(page: Page) {
    this.active = new TableComponent(page.getByTestId('active-orders'));
    this.archive = new TableComponent(page.getByTestId('archived-orders'));
  }
}

У тесті обидві таблиці — це той самий клас із різним коренем:

test('скасоване замовлення переїжджає в архів', async ({ page }) => {
  const dash = new DashboardPage(page);
  await dash.active.row('Замовлення #42').getByRole('button', { name: 'Скасувати' }).click();

  await expect(dash.active.row('Замовлення #42')).toHaveCount(0);
  await expect(dash.archive.row('Замовлення #42')).toBeVisible();
});

Що дивитися і чому:

• Скоупінг у межах кореня — ключ до перевикористання. Якби row() шукав через page.getByRole('row'), він повертав би рядки з обох таблиць одразу, і toHaveCount(0) став би неоднозначним чи впав на strict-mode. Пошук this.root.getByRole('row') бачить лише піддерево свого кореня.
• Один клас — обидві таблиці. TableComponent не прив'язаний до конкретного місця; передаси йому корінь active-orders чи archived-orders — і він працює. Той самий клас обслужив би й таблицю користувачів на іншому екрані.
• Це композиція, а не успадкування. DashboardPage містить дві таблиці як поля (has-a), а не успадковує їх. Спроба зашити спільну таблицю через BasePage дала б жорстку ієрархію, з якої два незалежні екземпляри на одному екрані витягти неможливо.
• Компонент віддає Locator під асерт, але не клікає ззовні за тест. row() повертає локатор навмисно — щоб тест зробив web-first expect(...).toBeVisible() з автоочікуванням. Дії (sortBy) лишаються методами всередині.

Кейс 3. Той самий фасад без браузера: API-клієнт для підготовки стану

UI-тест «користувач бачить свої замовлення» не повинен клікати реєстрацію й ручне створення замовлення — це повільно й крихко. Стан готуємо через API тим самим патерном: клас, що ховає протокол за методом мовою домену.

export class UsersApi {
  constructor(private readonly request: APIRequestContext) {}

  async create(user: NewUser): Promise<User> {
    const res = await this.request.post('/api/users', { data: user });
    expect(res.status(), 'фікстура користувача не створилась').toBe(201);
    return res.json();
  }
}

export class OrdersApi {
  constructor(private readonly request: APIRequestContext) {}

  async placeFor(userId: string, item: string): Promise<Order> {
    const res = await this.request.post('/api/orders', { data: { userId, item } });
    expect(res.status()).toBe(201);
    return res.json();
  }
}

Тест готує дані по API, а перевіряє через UI:

test('користувач бачить своє замовлення в списку', async ({ page, request }) => {
  const user = await new UsersApi(request).create({ email: 'qa+42@example.com', password: 'secret' });
  const order = await new OrdersApi(request).placeFor(user.id, 'Клавіатура');

  const login = new LoginPage(page);
  await login.open();
  await login.login({ email: user.email, password: 'secret' });

  await expect(page.getByTestId('orders-list')).toContainText(order.item);
});

Що дивитися і чому:

• UsersApi.create() — це той самий LoginPage.login(). Обидва ховають деталь протоколу за методом домену: там — селектор, тут — URL і метод HTTP. Зміниться контракт ендпоінта — правиш один клас, а не десятки тестів, що дьорбали /api/users напряму. Це доводить, що Page Object не про UI, а про фасад над протоколом.
• Підготовка стану через API швидша й стабільніша за UI. Прохід реєстрації кліками додав би секунди й точку флаку до кожного тесту, який лише потребує залогіненого користувача з замовленням.
• Асерт статусу тут — це перевірка інваріанта фікстури, а не бізнес-сценарію. expect(res.status()).toBe(201) усередині клієнта каже «стан справді підготувався»; це той самий дозволений виняток, що й перевірка «чи це та сторінка» у класичному page object. Бізнес-перевірка (замовлення видно в списку) лишається в тесті.
• Метод повертає дані, а не сирий відгук. create() віддає розпарсений User, тож тест оперує user.id, а не res. Якби клієнт повертав назовні APIResponse, деталь протоколу знову витекла б у тест — та сама протікаюча абстракція, що й повернений Locator.

Навіщо POM і що це таке

• Можу назвати дві біди, які лікує page object: дублювання кроків і крихкість тестів через розсипані по сюїту локатори.
• Розумію головну цінність — єдине джерело істини для локатора: зміна верстки правиться в одному класі, а не в кожному тесті.
• Знаю, що page object говорить мовою домену (login(user)), а тест не мислить селекторами й DOM.

Анатомія класичного page object

• Знаю, що мінімальний page object — це рівно локатори + дії, і нічого зайвого (без тест-даних і бізнес-логіки продукту).
• Розумію, чому наша конвенція тримає локатори private: інакше деталь реалізації протікає назад у тести — і знаю, що офіційний приклад Playwright оголошує їх публічними.
• Можу пояснити, чому метод має описувати намір (login), а не механіку (clickLoginButton).
• Знаю наше правило: page object віддає дані або стан (getErrorText), а не сирий Locator/WebElement; джерельної опори в нього немає.

Playwright vs Selenium

• Розумію, що Locator у Playwright лінивий (зберігає рецепт пошуку), тому в конструкторі безпечно оголошувати локатори ще до завантаження сторінки.
• Знаю природу StaleElementReferenceException у Selenium (@FindBy/WebElement) і чому лінивий локатор Playwright її не має.

Холівар про перевірки

• Розумію, що єдиного припису тут немає, і вмію назвати модальність кожного з трьох джерел, а не лише його висновок.
• Знаю позицію Фаулера і те, що це власна позиція автора («I favor»), а не норма: page object віддає стан — тест вирішує, що правильне; виняток — перевірка інваріантів сторінки.
• Знаю припис Selenium і те, що він нормативний: should never плюс рівно один обов'язковий виняток — перевірка завантаження сторінки під час створення об'єкта.
• Знаю, що Playwright припису не дає, але в офіційному прикладі імпортує expect у файл page object і тримає локатори публічними — тобто демонструє протилежне кодом.
• Знаю окрему позицію збоку: дока Cypress називає спільні page object'и антипатерном і радить програмний логін та керування станом застосунку — це про шаринг об'єкта, не про місце асерту.
• Знаю контраргумент практиків: дрібні assert-методи всередині проти дублювання простих перевірок у багатьох тестах.
• Розумію головне правило: не змішувати дію і перевірку її результату в одному методі (loginAndCheckSuccess — антипатерн); web-first assertions послаблюють спокусу ховати очікування всередині.

Fluent та навігація

• Розумію, чому класичний fluent через this погано лягає на асинхронний Playwright (Promise<this> читається гірше за окремі await).
• Знаю корисну форму fluent — повертати наступний page object з методу навігації (кодує дозволені переходи в типах); мінус — жорсткіша зчепленість.

Від сторінок до компонентів

• Розумію, чому «одна сторінка — один клас» ламається: хедер, таблиця, модалка повторюються на десятках екранів — і що першоджерело патерна від початку радило будувати об'єкти на значущі елементи, а не на цілі сторінки.
• Знаю різницю композиція (has-a) vs успадкування (is-a) і чому глибокі ієрархії BasePage → AdminUsersPage крихкі.
• Можу пояснити, навіщо компонент звужує скоуп пошуку до кореневого Locator, а не шукає по всій сторінці.
• Впізнаю god object (усталений антипатерн ООП: багато незвʼязаних методів і типів; на практиці — клас на 1500 рядків і конфлікти в мерджі) і лікую його розбиттям на компоненти за принципом єдиної відповідальності.

Той самий принцип поза UI

• Можу пояснити, що API-клієнт — той самий Page Object: UsersApi.create() ховає URL і метод HTTP так само, як login() ховає селектор; корисний для швидкої підготовки стану через API.
• Розумію критику POM (змішує локатори, дії, іноді перевірки) і що патерн Screenplay розводить ці ролі.