Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Візьміть залежний UI test і відокремте browser state від server-side test data.
Замініть випадковий CSS/XPath на user-facing locator там, де є semantic contract.
Запустіть test без retry, зафіксуйте root cause і лише потім порівняйте report із retry enabled.
Незалежний test, locator rationale і report, де retry не приховує root cause.
Test, який упав під час першого run, але пройшов retry. Playwright відрізняє його від passed і failed; default retries дорівнює zero.
Playwright abstraction, яка повторно знаходить актуальний DOM element перед кожною action та підтримує auto-waiting і retry-ability.
3. Селектори та пошук елементів →429 означає забагато запитів за визначений сервером період. Response може містити Retry-After; quota й backoff визначає test environment, а не pytest або Playwright.
2. Pytest fixtures, playwright fixture, прараметризація тестів →Опишіть cloud і local paths від початку recording до готового transcript.
Позначте permissions, temporary files, user-visible status і точку retry.
Визначте, які дані не повинні залишати device без окремої згоди.
Flow diagram або таблиця states з privacy boundary та recovery path.
`while` повторює блок, поки умова truthy. У retry-прикладі є `attempt`, `max_attempts`, пауза та обов’язкове `attempt += 1`; без оновлення counter цикл зависне. Для реальних UI-тестів framework-native waits кращі за ручний polling, але bounded `while` може бути корисним для контрольованої перевірки backend state.
Middle має орієнтуватися у standard library та основних конструкціях мови: collections, functions, reserved words/operators, способи створення й перетворення даних. Це дає змогу використовувати вбудовані можливості замість зайвих dependencies і custom wrappers. Окремий практичний блок — діагностика flaky tests: відрізнити проблему очікування, нестабільні дані, shared state, зовнішню залежність або справжню race condition. `retry` не є виправленням першопричини. Для дизайну automation code достатньо впевнено застосовувати KISS, DRY, YAGNI та DAMP. SOLID і design patterns корисні як словник для конкретних проблем, але не як вимога створювати багатошарову архітектуру. Також потрібно вміти запускати suite у CI та читати test report.
Другий поширений варіант Page Object — оголошувати element getter як метод із `@property`. З тесту він виглядає як поле, але `find_element()` виконується лише під час звернення. Це відкладає пошук і зменшує ризик зберегти element reference надто рано. Через property можна викликати `clear()`, `send_keys()`, `click()` або читати `is_selected()`. Для дії, яка потребує очікування, все одно краще мати окремий метод: property не перетворює Selenium на lazy locator і сама по собі не додає retry. Якщо агент або IDE має працювати з незнайомою бібліотекою, урок радить дати йому локальний source code як контекст. Це допомагає звірити реальні методи та актуальну реалізацію замість вигадування API за пам’яттю.
Locator-based explicit wait вирішує stale reference тим, що на кожній спробі знаходить актуальний DOM-вузол. Це ще одна причина зберігати локатор, а не довгоживучий `WebElement`. Implicit wait радять залишити нульовим і не змішувати з explicit waits: інакше внутрішнє очікування кожного `find_element()` додається до зовнішнього polling, через що реальний timeout стає непередбачуваним. Практичне завдання — зробити `BasePage`, окремий wait helper і Page Object у вибраному locator-based стилі.