Load readiness check
Виняткова перевірка всередині Page Object, яка підтверджує, що правильна page та її critical elements готові до operations; business assertions залишаються в test code.
Неймінг та структура automation-проєкту →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
Відокремити 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.
Розділити рольовий сценарій
Візьми тест, який допускає Free або Enterprise через if, і розділи його на дві fixtures та два тести з однозначними assertions.
Кожен тест має одну відому роль до першої UI-дії.
У test body немає гілки, що вибирає очікування за фактичним тарифом.
State-файли не містяться в Git.
Що змінилося після запису
У відео networkidle розглядається як один зі станів готовності сторінки.
Поточна документація позначає networkidle як discouraged для testing і радить перевіряти readiness через web assertions.
Auto-waiting і динамічні assertions
Перед діями Playwright автоматично перевіряє actionability елемента: видимість, стабільність, можливість отримувати події та, залежно від операції, `enabled` або `editable`. Через це для звичайних `click`, `fill`, `hover` чи drag-and-drop не потрібно вручну дублювати очікування, типові для Selenium. Вбудовані Playwright assertions також повторюють перевірку до timeout, тому в них потрібно передавати `Locator`, а не вже отримане статичне значення. Автор називає сторінку документації про auto-waiting ключовою та застерігає від бездумного додавання `waitFor` перед кожною дією.
Generated assertions і їх межі
Assertion generator може створити fluent `hasName`, `hasCode` та інші methods з model classes. Розглядаються hard і soft assertions, package include/exclude та custom templates. Live demo виявляє plugin/version/import failures. Урок: generated assertion code потрібно компілювати у clean build і review, а не вважати generator output правильним за замовчуванням.
Перший тест і strict locator semantics
У перенесеному тесті навігація виконується через `page.navigate`, пошук — через `page.locator`, а перевірка — через Playwright assertions. Тест запускається у браузері й успішно проходить після коригування локатора. Playwright locator може описувати кілька DOM-вузлів, але операція, що очікує один елемент, завершується помилкою strict mode. На відміну від Selenium `findElement`, який із множини повертає перший збіг, у Playwright потрібно зробити locator унікальним або явно вибрати `first`; правило стосується і дій, і assertions.
AssertJ і перевірка колекцій
Для assertions підключається AssertJ Core, яку автор радить для різних data types і особливо collections. Оскільки suites endpoint повертає масив, тест перевіряє, що list actual titles містить title щойно створеного suite. Перевірка лише title через JsonPath не масштабується на description та інші fields. Тому наступний крок — deserialization повного response в typed Java object і assertions проти його полів.
Assertions у тесті і перехід до DTO
Первинні перевірки мають бути видимими в тесті, а не захованими в controller. Тому API method повертає `Response`, а test явно перевіряє status code. Така структура спрощує code review і показує, що саме доводить сценарій. Наступний крок — замінити JSON strings на data transfer objects, щоб мати Java types, autocomplete і зручне оновлення полів. Додаються Java Faker для унікальних test data і Lombok для генерації boilerplate. Для Lombok у IntelliJ IDEA потрібні plugin і ввімкнений annotation processing.
Як команда й 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 показує інше.
Динамічні й одноразові assertions
Selenide condition на кшталт `shouldHave(text(...))` очікує потрібний стан протягом певного часу, тоді як `getText()` плюс JUnit assertion читає значення лише один раз. Якщо frontend спочатку показує `0`, а потім `102`, одноразове читання може зробити тест flaky. Перед статичною числовою перевіркою слід хоча б дочекатися видимості або іншої надійної precondition; повторюваний parsing виноситься в один method.
Intent-level methods для assertions
Низькорівневі selector, collection і parsing operations виносяться в methods на кшталт `countOfProjectsShouldBeEqualTo`, `countOfTestCasesShouldBeEqualTo` та перевірку total count. Test method після цього показує намір сценарію й очікувані числа, а не деталі DOM. Параметри `expectedSize` або `expectedCount` дають використовувати ті самі перевірки з різними даними.
Fluent response assertions і business-readable API
Над `Response` будується small fluent wrapper: status, typed body, field/domain assertions, завершення chain. Це дає тесту domain vocabulary і прибирає repeated parsing. Важливо не сховати expected behavior за великим «validateEverything». Fluent method має виражати одну observable property і давати specific failure.
Assertions, status codes і реальний debugging
Після create виконується `GET` і response data порівнюються з generated input. Помилки `400`/`500` розбираються через actual request/response, а не через здогад. Відео навмисно залишає неідеальний demo API і live debugging. Це добре показує межу між client defect, unstable shared test API і real server defect.