Відеобібліотека
Пошук у нотатках курсу Design Patterns для автоматизаторів з переходом на потрібну секунду.
Wrapper розділяє locator actions і conditions. Condition має метод `verify`, який отримує locator та викликає native Playwright expectation; concrete conditions реалізують visible, hidden, text та інші стани. Locator wrapper повертає себе після action або verification, тому Page Object читається як короткий fluent scenario. Custom waiting library пропонується лише для рідкісних conditions, яких немає в Playwright; основні очікування не переписуються.
Приклад лишається на Java, але той самий маленький wrapper можна реалізувати на Python, C# або TypeScript. Для JavaScript/TypeScript автор радить TypeScript через типізацію. На проєктах, де architecture дозволяє тестувати основну логіку на API-рівні, UI-suite може складатися приблизно з десяти ключових flows. Тоді мінімальна обгортка, Page Objects і Trace Viewer дають достатню підтримуваність без створення ще одного великого framework.
Raw Selenium створює повтори `findElement`, waits і JavaScript executor workarounds, тому починати радять хоча б з існуючого wrapper на кшталт Selenide. Змішування implicit та explicit waits додатково робить runtime і причину затримки непередбачуваними. На CI test code, Selenium Server і browser можуть працювати на різних machines. Кожна remote команда додає network latency та навантаження Grid/Selenoid, тому велика кількість дрібних звернень до browser різко збільшує загальний час.
Playwright Java розділяє locator actions і assertions: для перевірки потрібно окремо передавати locator в assertion API. Після action не завжди можна продовжити читабельний chain на тому самому object, тому Page Object наповнюється повторними locator calls. Автор прагне до Selenide-подібного стилю: знайти element, викликати `shouldBe`/`shouldHave`, виконати `click`, `setValue` або `press`, читаючи chain зліва направо. Замість великого framework потрібен вузький wrapper над уже наявними Playwright capabilities.
Playwright trace зберігає actions, before/after snapshots, console, network requests, request/response bodies і metadata. Це дозволяє відкрити локальний Trace Viewer та побачити, що відбулося перед failure, без повторного запуску. Trace artifact може бути десятки megabytes, але часто дає більше діагностичної інформації за video. На CI варто зберігати trace для кожного test або при failure й публікувати його як downloadable artifact чи у власному hosted viewer. **Актуальність станом на 2026-08-08.** Низькорівневий `BrowserContext.tracing()` у Playwright Java записує browser operations і network activity, але не test assertions. Це обмеження треба врахувати, якщо wrapper обіцяє повний assertion-aware trace ([Playwright Java documentation](https://playwright.dev/java/docs/api/class-tracing)).
Browser можна ініціалізувати один раз, але `BrowserContext`, `Page` і tracing потрібно створювати перед кожним test та закривати після нього. Один trace на весь suite буде надто великим і незручним для rendering. Для JUnit 5 wrapper реалізує `BeforeEachCallback`/`AfterEachCallback`; для TestNG потрібен listener з обробкою success, failure і skip. Автор віддає перевагу JUnit 4/5 через cleaner extension ordering, lifecycle і parameterization, вважаючи TestNG listeners та shared initialization складнішими.
Для native iOS згадується XCUITest, для Android — Espresso з wrapper на кшталт Kaspresso/Kakao, для React Native — Detox, для Flutter — Flutter Driver. Native tools мають коротший шлях до UI й швидше реагують на оновлення екрана. Складні canvas/builders, custom maps і довільна graphics interaction можуть бути дешевшими для ручної перевірки або вимагати окремої testability роботи з розробниками. Форми, списки та типові business flows автоматизуються значно простіше. **Актуальність станом на 2026-08-08.** Для нових Flutter integration tests офіційна документація веде до пакета `integration_test`, а для наявних `flutter_driver` suites дає окремий migration path ([Flutter documentation](https://docs.flutter.dev/release/breaking-changes/flutter-driver-migration)).
Wrapper навмисно використовує Selenide-подібні method names, щоб existing Page Objects мігрували через import replacement і мінімальні structural changes. Selenium та Playwright tests можуть тимчасово жити в одному repository й запускатися різними commands. IntelliJ Structural Search and Replace або regex replacement допомагають перетворити `@FindBy`, Page Factory і повторювані `driver.findElement` patterns. Якщо old suite непослідовний, безпечніше переписувати test лише коли його торкається зміна, а не робити ризиковий big-bang rewrite.