Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
CSS зручно рухається вниз або між siblings, але в показаному сценарії не дає зручного способу піднятися до parent або далекого ancestor. XPath дозволяє знайти стабільний label, перейти до `parent` або вибрати `ancestor` з потрібним `id`, а вже в його межах знайти input. У фінальному прикладі так знаходиться hidden token input, після чого Selenide `getValue()` зчитує значення його `value` attribute.
Перед автоматизацією сценарій треба пройти вручну з відкритими DevTools. HTML — це мова розмітки, де документ складається з елементів, тегів, атрибутів і їхніх значень. Для пошуку елементів використовуються `id`, `name`, стабільні `data-*` атрибути, CSS або XPath. У відео перевага надається компактним CSS-селекторам; XPath залишається для випадків, де CSS не виражає потрібний зв’язок.
Метод `find(String locator)` визначає тип локатора: рядок, що починається зі `/`, перетворюється на `By.xpath(...)`, інакше використовується `By.cssSelector(...)`. У відео це реалізовано компактним ternary operator; також показано еквівалент через `if/else` і обговорено компроміс між короткістю та читабельністю. `find` повертає `ElementActions`, а сам driver береться з `WebDriverProvider`. Після заміни прямих `driver.findElement(...)` тест стає компактнішим, але зберігає проблему: пошук усе ще може виконатися до того, як елемент стане видимим або доступним для дії.
Колекція потрібна, коли один конкретний елемент складно знайти напряму або коли однакову перевірку треба виконати для групи елементів. Практичний підхід — знайти всі відповідні елементи, відфільтрувати їх за критерієм і далі працювати з результатом. Selenide за замовчуванням працює з колекцією динамічно: під час наступної перевірки він може знову виконати пошук за селектором, а не покладатися на раз назавжди зафіксований список DOM-вузлів. У демонстрації розглядаються варіанти пошуку всіх елементів, зокрема `$$` і `$$x`; для XPath є окремий короткий запис. Пошук колекції варто починати зі структури HTML: визначити контейнер і повторювані елементи на кшталт `ul` та `li`. Семантичні теги полегшують читання сторінки не лише тесту, а й accessibility-інструментам; якщо селектор неминуче неочевидний, йому дають предметну назву.
Проєкт розділяється на окремі пакети для Selenide і Selenium, після чого той самий сценарій переписується через `driver.findElement(...)`, `By.cssSelector(...)`, `sendKeys(...)` і `click()`. Для текстового локатора, якому немає прямого аналога `By.text`, використовується XPath. Механічна заміна Selenide-викликів допомагає швидко отримати початковий варіант, але залишає багатослівний код і не додає очікувань. Тому наступний крок — явно визначити, коли елемент готовий до пошуку, перевірки або дії.
Для важливих або частих перевірок радиться розглянути native інструменти: XCTest/XCUITest на iOS та Espresso або зручнішу обгортку Kakao на Android. Такі тести ближчі до застосунку, швидше виконуються і зрозуміліші mobile developers, які можуть запускати їх локально та в CI. Автоматизатор має покращувати testability самого продукту: додавати або просити додати стабільні `accessibilityIdentifier`, `accessibilityLabel`, Android `resource-id` і content descriptions. Native selectors, predicates і class chains зазвичай кращі за XPath. Якщо команда контролює source code, стабільний атрибут дешевший за постійне ускладнення locator-а в зовнішньому test suite.
Глибокі XPath не дають переваги в Playwright: потрібні parent/child operations уже є в locator API, а важливішу бізнес-логіку часто краще перевіряти нижче за UI. Команда автоматизації має домовитися з frontend developers про підтримку test attributes і, за можливості, додавати їх через звичайний pull request. Для публічного production DOM слід окремо оцінити, чи не спрощують описові IDs scraping або розкриття внутрішньої структури.
HTML конкретного елемента можна передати моделі й попросити locator для Playwright або Selenium, уточнивши правила про allowed attributes і partial match. Це швидше за вивчення синтаксису складного XPath, але результат треба перевірити на сторінці. Ще надійніше — мати read access до frontend source, знайти компонент і додати стабільний атрибут у тому самому delivery process.
Для assertions слід використовувати API, що повертає `Locator`: `locator(...)`, `getByRole(...)`, `getByText(...)` та споріднені методи. У документації Playwright пріоритет надається user-facing locator-ам, але відео рекомендує не перетворювати це на механічне правило й підбирати locator за реальним DOM та потребами команди. Playwright розширює CSS-пошук перевірками тексту, видимості й відносного розташування, однак надто складні конструкції та XPath ускладнюють підтримку. Якщо стабільного сигналу немає, краще домовитися з розробниками про data attribute; `getByTestId` фактично є зручною обгорткою над таким контрактом.
Повторювані `@BeforeAll` і `@AfterAll` замінюються JUnit 5 extension. `WebDriverLifecycleExtension` реалізує `BeforeAllCallback` та `AfterAllCallback`: до тестів ініціалізує driver через provider, після тестів закриває його. Клас підключається через `@ExtendWith`, тому setup/teardown більше не дублюються в кожному test class. Окремий login extension виконує авторизацію перед тестовим класом. Такі розширення дозволяють комбінувати потрібні preconditions без спільного base class. Наприкінці до wrapper додається `findByText(...)`, який будує XPath і повертає той самий тип actions; тест запускається після виправлення синтаксису локатора.