Python мануфактураJavaDesign Patterns для автоматизаторів

Java · Основний курс · 1:05:26–1:13:18

Tracing і готовий JUnit integration

Tracing записує кроки тесту, screenshots, console logs, network requests і додатковий контекст виконання. Ручна реалізація потребує browser context, запуску tracing перед тестом і збереження archive після нього. Замість власного extension демонструється експериментальна на момент відео JUnit integration з `@UsePlaywright`, яка інжектить `Page`. Для параметризації створюється клас, що реалізує `OptionsFactory`: через нього задаються headed/headless mode, base URL, tracing policy, browser launch options та інші параметри. За замовчуванням запускається Chromium build Playwright. Через browser channel можна обрати встановлений Google Chrome, а `slowMo` додає паузу між операціями, що корисно для демонстрації або візуального аналізу швидкого тесту.

Playwright для Java: основи та поглиблення →

Java · Основний курс · 1:35:21–1:39:30

Практичні висновки й домашня робота

Playwright рекомендується як швидша й зручніша основа для UI automation, особливо на remote execution. У Java повторювану ініціалізацію можна прибрати через JUnit integration, Page Object-и та невелику application facade, а стабільність дій забезпечують auto-waiting і динамічні assertions. Для домашньої роботи потрібно переписати на Playwright наявний Selenium-сценарій, налаштувати browser options, увімкнути tracing, відкрити trace локально та використати `page.pause()` або recorder для налагодження. Згенеровані recorder-ом кроки слід переносити вибірково й узгоджувати locator strategy в межах команди. `getByRole` додатково перевіряє accessibility semantics сторінки: сучасні Angular і React components мають формувати ролі та ARIA attributes, які screen reader розпізнає як кнопку, поле введення чи інший control. Для колекцій strict locator semantics складніша, тому в більшості дій варто будувати locator, що знаходить один конкретний елемент.

Playwright для Java: основи та поглиблення →

Java · Сесії: AMA та PMP · 0:00–4:40

Від публічного 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.

Як Playwright взаємодіє з браузером через протокол →

Java · Advanced: API-автоматизація · 1:10:00–1:30:00

Error contracts і tracing

Generated success client не завжди зручний для negative tests. API має повертати standardized error model з code, message і diagnostic fields, щоб frontend і tests могли відрізнити конкретні failures в межах одного HTTP status. Test-generated correlation/trace ID передається у header, логується і додається до report. Тоді розробник знаходить повний distributed trace для failed test, а не шукає за приблизним timestamp.

Кодогенерація через OpenAPI Generator →

Java · Основний курс · 1:13:18–1:16:02

Аналіз прогону у Trace Viewer

Після прогону tracing створює ZIP archive. Автор не радить завантажувати внутрішні дані застосунку в online Trace Viewer; локально archive відкривається командою `npx playwright show-trace <path>`, для чого на машині має бути встановлений Node.js Playwright package. Trace Viewer показує стан before/after для кожної дії, screenshots, snapshot сторінки та network requests. Завдяки цьому trace може бути основним діагностичним артефактом CI-прогону й давати значно більше контексту, ніж звичайний screenshot після падіння.

Playwright для Java: основи та поглиблення →

Java · Основний курс · 1:16:02–1:25:30

Application facade і потокобезпечна ініціалізація

Щоб не створювати Page Object-и безпосередньо в кожному тесті, будується невеликий application facade. Він один раз приймає `Page`, створює `HomePage`, `SignInPage`, `ProjectsPage` та інші сторінки у правильному порядку й віддає їх тесту через короткі методи. Під час рефакторингу перевіряється момент ініціалізації: Page Object-и не можна створювати раніше, ніж JUnit integration надасть валідний `Page`. Після перенесення створення у constructor application object отримується стабільний lifecycle без повторюваних `new ...Page(page)` у тесті. У вбудованій Playwright JUnit implementation показано зберігання instances через `ThreadLocal`. Це дає окремі Playwright, Browser, BrowserContext і Page для кожного test thread; tracing lifecycle додатково враховує завершення, падіння або скасування тесту.

Playwright для Java: основи та поглиблення →
Запитати в чаті про «tracing» →