Assertions
Підтверджує й актуалізує поняття уроку: Auto-retrying assertions.
1. Рефакторинг та оптимізація, KISS, DRY, DAMP, YAGNI → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Load readiness check
Виняткова перевірка всередині Page Object, яка підтверджує, що правильна page та її critical elements готові до operations; business assertions залишаються в test code.
Неймінг та структура automation-проєкту →Playwright Codegen
Офіційний test generator, який відкриває browser і Playwright Inspector, записує actions та пропонує locators і assertions.
4. Playwright плагіни та codegen →Typed configuration і пароль, невалідний за явною policy
Приклад створює frozen configuration і генерує пароль довжиною 10, який гарантовано порушує задану в прикладі minimum-length policy 12.
Assertions проходять, друкується student@example.test.
Відокремити local state від instance state
Створи два PageObject instances із різними page values і доведи assertions, що зміна local variable не змінює self.page іншого instance.
Обидва instances мають незалежні page attributes.
У method немає global state.
Автор може пояснити, чому obj.method() передає obj як перший argument.
Матриця перевірок створення ресурсу
Для одного POST endpoint опишіть immediate response assertion і спосіб перевірки eventual result.
Додайте resource-schema assertions і один business-flow assertion.
Позначте, який тест локалізує кожен failure.
Таблиця з чотирма checks, test level і failure signal.
Pick locator і генерація assertions
У Codegen можна перемкнутися з повного запису на Pick Locator і вибирати окремі елементи. Режими assertions генерують перевірки видимості, тексту або значення: ```python expect(page.get_by_text("Invalid email or password")).to_be_visible() ``` або перевірки вмісту контейнера через `to_contain_text`. Практичний цикл: записати короткий сценарій, скопіювати код у PyCharm, запустити його, а потім прибрати зайві дії та виправити локатори. Саме так автор свого часу використовував recorder для вивчення Playwright API.
Як команда й assertion доходять до browser
[Дивитися з 40:00](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=2400s). Кілька переходів у implementation показують ланцюг від `Locator.click()` до frame/channel command. Client збирає action options і надсилає повідомлення через connection; browser-side layer виконує пошук, actionability checks і дію. Під час дослідження автор спочатку припускає, що assertions повністю виконуються в Python client, а потім знаходить protocol command для locator expect. Практичний урок тут важливіший за конкретний internal class: перевіряти припущення переходом у реалізацію, trace або protocol logs і явно коригувати висновок, коли source code показує інше.
Які оператори потрібні в автоматизації
Оператори відповідають на практичні питання: чи збіглося actual з expected, чи значення ініціалізоване, чи виконано дві умови, чи status code належить дозволеному набору та як порахувати очікувану кількість сторінок або total price.
Від публічного API до реалізації Locator
[Дивитися з 00:00](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=0s). Playwright складається з багатьох частин: browser lifecycle, locators, actions, assertions, downloads, reporting і tracing. Щоб відповісти на питання «що відбувається під капотом», автор відкриває реалізацію `Locator`, а не обмежується документацією верхнього рівня. `Locator` зберігає frame і спосіб пошуку елемента, а додаткові умови на кшталт `has`, `hasText` чи visibility-related filters добудовують запит. У Python named arguments роблять таку композицію схожою на Builder без окремого builder class. Практичний висновок: перед створенням власного selector DSL варто перевірити вже наявні аргументи конструктора й методи locator API.
Логічні `and` та `or`
`and` повертає truthy результат лише коли правдиві обидві сторони, наприклад status code `201` і наявний user ID. Для `or` достатньо однієї правдивої умови, наприклад response code `200` або `201`. У тестах кілька зрозумілих assertions часто діагностуються краще за одну велику складену умову.
Дані створюються в preconditions тесту
Генерацію важливих test data краще явно виконувати на початку тесту й передавати результат у helper, а не непомітно ховати всередині `registerUser()` чи `createCompany()`. Так сценарій показує свої preconditions, а той самий expected object доступний для подальших assertions. Business step може повернути оновлену модель, якщо система присвоїла ID, status або інші server-generated поля.
Що зберігає Playwright `page`
Playwright `Page` представляє окрему вкладку або сторінку в browser context. Переданий у Page Object екземпляр визначає, з яким саме браузерним контекстом працюватимуть locators, переходи й assertions. Збереження `page` як `self.page` прибирає потребу передавати його в кожен метод. Залежність залишається явною в initializer, а всі дії конкретного Page Object використовують одну й ту саму вкладку.
Перевіряти mapping на кожному етапі
Одна сутність може мапитися різними backend endpoints, DTO та frontend components. Старий copy-paste або неповний refactoring часто дає `undefined`, різне форматування чи пропущене поле лише на проміжній сторінці. Автоматизація може дешево перевірити expected data після створення, у списку, деталях, recently viewed та після update, а не лише в кінцевій точці сценарію.
`match/case` і вибір простої конструкції
`match/case` зручний для багатьох чітких варіантів на кшталт окремих auth codes, але для двох-трьох ranges звичайний `if/elif` часто простіший. Розширені приклади пропонують додати assertions і exceptions та подивитися, як змінюється failure output.
Практика на об’єктах
Домашня частина — пройтися по list of objects, додати `enumerate`, перевірити поля всередині циклу та дослідити `break`/`continue`. Failure message має зберігати контекст проблемного елемента, інакше цикл ускладнить діагностику.