Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Якщо стабільного test ID або accessible name немає, припустимий короткий CSS selector через зрозумілий parent і тип дочірнього елемента. Locator повинен читатися; складний вираз варто сховати за змінною з предметною назвою. Не слід використовувати generated hashes, випадкові class names, positional indexes або повні DOM paths. Якщо ID має стабільний префікс і випадковий suffix, можна шукати за контрольованим частковим збігом.
Selector з назвою project формується через `String.format`, де `%s` замінюється на `targetProjectName`. Після фільтрації видимих items тест спочатку підтверджує, що знайдено рівно один результат, потім бере цей element і шукає потрібний дочірній `p` відносно нього. Це прибирає повторний глобальний пошук і зберігає зв’язок assertion з уже перевіреним project item.
[Дивитися з 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.
Елемент за class шукається через `.class-name` або attribute selector на кшталт `[class*='class-name']`. Два classes одного елемента записуються без пробілу: `.first.second`. Tag та `id` або attribute також можна комбінувати, наприклад `turbo-frame#global_search_results`. Якщо attribute value містить пробіл або спеціальні символи, його треба брати в лапки. У Java-рядку single quotes всередині CSS зменшують кількість escaping.
Ще один експеримент — sidebar, який об’єднує кілька LLM interfaces і передає їм виділений на сторінці текст або HTML fragment. Для automation engineer це скорочує шлях від inspect element до prompt: можна вибрати DOM block і попросити запропонувати locator або page object. Це не замінює перевірку selector-а. Згенерований варіант треба оцінити за semantics, uniqueness і stability у реальному DOM, але інструмент прибирає кілька механічних copy/paste дій.
HTML конкретного елемента можна передати моделі й попросити locator для Playwright або Selenium, уточнивши правила про allowed attributes і partial match. Це швидше за вивчення синтаксису складного XPath, але результат треба перевірити на сторінці. Ще надійніше — мати read access до frontend source, знайти компонент і додати стабільний атрибут у тому самому delivery process.
Playwright пропонує `getByRole`, `getByLabel`, `getByText`, `getByPlaceholder` та інші user-facing locator-и. `getByRole` спирається на accessibility semantics і допомагає перевіряти, чи інтерфейс коректно описує кнопки, поля та таблиці для screen reader; особливо зручним такий пошук може бути для рядків і колонок таблиці. Автор водночас застерігає, що role-based locator-и іноді складніше читати й діагностувати команді. Для більшості проєктів він радить обирати найпростіший стабільний CSS selector або узгоджений data attribute, а accessibility locator використовувати там, де він справді дає читабельний і надійний контракт. API портів Playwright загалом однаковий у Java, Python, C# і TypeScript. Практична перевага TypeScript-версії в тому, що власний Playwright Test runner автоматично надає готовий `Page`; у Java lifecycle потрібно організувати через JUnit або власну обгортку.
Замість довгого `sleep` тест запускається в debug mode з breakpoint, щоб дослідити DOM у потрібному стані. Автор перевіряє `h2`, link з текстом `Read Me` та вкладені елементи, уточнюючи selector до єдиного збігу. Важливе спостереження: контент або DOM-елемент може з’явитися раніше, ніж зміна стане помітною користувачу, тому умова завантаження має відповідати потрібному business state, а не випадковому швидкому елементу.
Одна стратегія спочатку знаходить елементи за структурним селектором, а потім перевіряє їхній текст. Інша одразу знаходить елементи за текстом і перевіряє розмір отриманої колекції. У виміряному прикладі прямий пошук за текстом із перевіркою розміру виявився швидшим за фільтрацію вже знайденої колекції, але автор радить вибирати підхід за конкретною сторінкою та власними вимірами. Після пошуку одного контейнера можна знайти всередині нього колекцію. Зворотний chaining — отримати колекцію через `$$`, а потім одразу застосувати пошук одного дочірнього елемента до всієї колекції — не працює як пошук у кожному елементі. Для цього треба пройти колекцію циклом і виконати дочірній пошук для кожного `SelenideElement`.
Метод `find(String locator)` визначає тип локатора: рядок, що починається зі `/`, перетворюється на `By.xpath(...)`, інакше використовується `By.cssSelector(...)`. У відео це реалізовано компактним ternary operator; також показано еквівалент через `if/else` і обговорено компроміс між короткістю та читабельністю. `find` повертає `ElementActions`, а сам driver береться з `WebDriverProvider`. Після заміни прямих `driver.findElement(...)` тест стає компактнішим, але зберігає проблему: пошук усе ще може виконатися до того, як елемент стане видимим або доступним для дії.