Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Створюється Java/Gradle project з group/package naming, JUnit Platform і dependencies. Відео використовує Java 11/17 і пояснює різницю Maven та Gradle як build tools. Repositories та artifact storage потрібні не лише для third-party libraries: компанія може публікувати власні clients і test artifacts. Точні dependency versions мають бути pinned і відтворювані на CI.
Щоб не створювати чотири Playwright instances у кожному тесті, демонструється JUnit 5 extension із `BeforeAllCallback` і `AfterAllCallback`. Він запускає Playwright і браузер перед тестами класу, надає `Page`, а після виконання закриває ресурси у зворотному порядку. Перша спроба взяти `Page` зі static field у тесті дає порожнє значення, бо static initialization відбувається раніше за callback extension. Виправлення — зберігати `Page` всередині extension і отримувати його методом уже після запуску lifecycle. На локальному headed-запуску Playwright контролює браузер так, що звичайний рух курсора не перехоплює тестові дії. Це протиставляється Selenium, де взаємодія користувача з тим самим браузером може змінити focus і зламати сценарій.
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` додає паузу між операціями, що корисно для демонстрації або візуального аналізу швидкого тесту.
Залежність `com.microsoft.playwright` знаходиться через Maven repository і додається у `build.gradle`; для Maven-проєкту потрібно обрати відповідний dependency snippet. Після синхронізації імпорт перевіряється через External Libraries, а сам тест створюється як JUnit test у пакеті Playwright. Показано також конвертацію невеликого Selenium/Selenide прикладу в Playwright за допомогою LLM. Такий інструмент доречний для локального рефакторингу або перенесення синтаксису між мовами й бібліотеками, але початківцю все одно важливо самостійно писати код і вміти знаходити документацію. Прямий Java API вимагає явно створити `Playwright`, `BrowserType`, `Browser` і `Page`. Нову вкладку створюють через browser context, тому автор вважає базовий API низькорівневішим за Selenide та радить згодом сховати повторювану ініціалізацію.
Тест описується як method всередині class і позначається JUnit 5 annotation `@Test`. Важливо вибрати імпорт саме з `org.junit.jupiter.api`, бо IDE може запропонувати однаково названі типи з інших package. Java-класи називаються у PascalCase, methods — у camelCase; блоки обмежуються фігурними дужками, а statements завершуються `;`. IDE formatting і optimize imports прибирають механічні помилки, але не замінюють розуміння структури.
Щоб не створювати 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 додатково враховує завершення, падіння або скасування тесту.
Повторювані `@BeforeAll` і `@AfterAll` замінюються JUnit 5 extension. `WebDriverLifecycleExtension` реалізує `BeforeAllCallback` та `AfterAllCallback`: до тестів ініціалізує driver через provider, після тестів закриває його. Клас підключається через `@ExtendWith`, тому setup/teardown більше не дублюються в кожному test class. Окремий login extension виконує авторизацію перед тестовим класом. Такі розширення дозволяють комбінувати потрібні preconditions без спільного base class. Наприкінці до wrapper додається `findByText(...)`, який будує XPath і повертає той самий тип actions; тест запускається після виправлення синтаксису локатора.
Перед commit потрібно переглянути кожен changed line і переконатися, що `.env` не потрапив до repository. Gradle configuration коригується так, щоб tests можна було запускати з command line через `gradle test`, а не лише кнопкою IDE. `@BeforeAll` виконує спільний open/login один раз перед усіма tests, `@BeforeEach` може перевідкривати home page перед кожним test; наприкінці автор пропонує так само дослідити відповідні after hooks.
Повторюваний URL спочатку виноситься в змінну типу `String`. Оголошення задає тип і назву, а ініціалізація присвоює значення; неініціалізовану локальну змінну Java не дозволить використати. Тест у JUnit є методом з анотацією `@Test`, тому локальна змінна одного test method недоступна іншому, а спільне значення потрібно підняти на рівень test class.
Переписувати весь test suite з нуля зазвичай не потрібно. Коли старий тест зламався або нову задачу значно легше реалізувати новим засобом, її можна зробити на uv чи Playwright і залишити робочі старі тести на pip або Selenium. В одному репозиторії тимчасово можуть співіснувати: - pip і uv; - Maven і Gradle; - Selenium і Playwright; - pytest та інший test runner; - JUnit і TestNG. CI просто виконує окремі команди для відповідних наборів. Основний ризик — не саме співіснування, а конфлікти спільних транзитивних залежностей і додаткова вартість підтримки двох стеків. Найбезпечніший аргумент для міграції — конкретна користь на конкретному сценарії: швидше встановлення, простіша діагностика, потрібне мокання network або стабільніша робота з браузером. Після доказу підхід можна розширювати.