attribute selector
CSS selector, який відбирає elements за наявністю або значенням attribute, включно з exact і substring matching operators.
3. Селектори та пошук елементів →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
CSS attribute matching
Порівнює id shorthand, substring match і комбінування tag, classes та attribute.
Кожен selector знаходить лише intended element у відповідному DOM fixture.
3. Селектори та пошук елементів →Зібрати Page Object без довгоживучих WebElement
Створіть BasePage з wait-aware click() і type_text().
Збережіть локатори login page як tuple (By.CSS_SELECTOR, value).
Створіть предметний login() і перевірку success state.
Перерендерте один компонент у test page та переконайтеся, що дія повторно знаходить елемент за locator.
Тест читається через предметні Page Object methods і не використовує implicit wait або довгоживучі WebElement fields.
Стабілізувати Selenium-сценарій
Створіть pytest fixture з webdriver.Chrome() і гарантованим quit() після тесту.
Відтворіть вхід і пошук проєкту через By.CSS_SELECTOR.
Замініть перевірки після переходів на WebDriverWait з visibility_of_element_located.
Навмисно зламайте один locator і переконайтеся, що падіння вказує на очікувану умову.
Тест проходить без sleep і падає з діагностичним TimeoutException, якщо цільовий locator неправильний.
Явне очікування видимого елемента
Locator передається всередину expected condition, тому кожна спроба polling може повторно знайти актуальний DOM-вузол.
Повертається видимий WebElement або після 10 секунд виникає TimeoutException.
1. Selenium початок, основи, фікстури →Locator замість завчасно знайденого `WebElement`
`find_element()` є eager operation: команда одразу йде до WebDriver. Тому конструкція на кшталт `EC.visibility_of(driver.find_element(...))` не захищає від раннього `NoSuchElementException` — елемент уже намагалися знайти. Для елемента, який ще має з’явитися, використовується `EC.visibility_of_element_located((By.CSS_SELECTOR, selector))`. Condition отримує locator tuple і сам повторює пошук до успіху або timeout. Збереження `By.CSS_SELECTOR` у tuple також зменшує ризик переплутати тип локатора зі звичайним рядком. Різниця принципова: `is_displayed()` робить одне звернення до стану вже знайденого element ID, тоді як explicit wait повторює перевірку. Саме тому очікування треба прив’язувати до спостережуваного стану, а не просто додавати після будь-якого пошуку.
Власні postfix templates для Playwright
`Postfix Completion` налаштовується через Settings (`⌘,` на macOS). Postfix template застосовується до виразу ліворуч від крапки. Спеціальна змінна `$EXPR$` означає цей вираз, а `$END$` визначає, де залишиться курсор після розгортання. Створено кілька Python-шаблонів: - `"selector".locator` перетворює селектор на `page.locator("selector")`; - вираз із postfix `expect` обгортається в `expect(...)`; - скорочений варіант на кшталт `expvis` одразу створює `expect(...).to_be_visible()`. Під час першого налаштування `locator` вираз помилково був додатково взятий у лапки, через що PyCharm формував неправильний код. Після виправлення `$EXPR$` підставляється як готовий вираз. Це важливе правило: шаблон має додавати лише відсутню структуру, а не повторно форматувати вже валідний фрагмент. Такий ланцюжок скорочує типовий шлях до перевірки: знайти селектор, вставити його як рядок, застосувати `.locator`, а потім `.expvis`. Результат детермінований і не потребує повторної перевірки припущень генеративної моделі.
Перший сценарій: `get`, `find_element` і CSS-селектори
Тест відкриває URL через `driver.get(config.url)`, знаходить поля email і password та вводить значення через `send_keys()`. Кнопка входу знаходиться за CSS-селектором з атрибутом `value`, після чого викликається `click()`. На відміну від Playwright locators, у Selenium базовими операціями є `find_element()` і `find_elements()`. Перша повертає перший знайдений елемент або кидає `NoSuchElementException`, друга — колекцію всіх збігів. Якщо селектор неунікальний, `find_element()` може мовчки обрати не той вузол, тому локатор треба перевіряти на реальній сторінці. Тип пошуку задається явно, наприклад `By.CSS_SELECTOR`. Якщо CSS-селектор усередині Python-рядка містить подвійні лапки, зовнішній рядок зручніше обгорнути одинарними, щоб не псувати синтаксис зайвим escaping.
Читабельний CSS як практичний fallback
Якщо стабільного test ID або accessible name немає, припустимий короткий CSS selector через зрозумілий parent і тип дочірнього елемента. Locator повинен читатися; складний вираз варто сховати за змінною з предметною назвою. Не слід використовувати generated hashes, випадкові class names, positional indexes або повні DOM paths. Якщо ID має стабільний префікс і випадковий suffix, можна шукати за контрольованим частковим збігом.
Від публічного 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.
Від сирого сценарію до Page Object
Стартовий тест напряму викликає `driver.find_element()`, `WebDriverWait(...).until(...)` і браузерні дії. Він придатний для перевірки ідеї, але змішує бізнес-сценарій із технікою Selenium, тому наступний крок — дати діям читабельні назви й рознести їх по Page Objects. Замість Playwright `Page` у конструктор Page Object передається Selenium WebDriver. Спільний `BasePage` зберігає driver і один раз ініціалізує стандартне очікування, щоб кожен клас сторінки не дублював timeout та polling configuration. Найпрактичніше представлення локатора — tuple на кшталт `(By.CSS_SELECTOR, "...")`. Воно зберігає і стратегію, і значення пошуку та напряму сумісне з locator-based expected conditions.
Classes і комбінування ознак
Елемент за 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.
AI sidebar і робота з HTML-контекстом
Ще один експеримент — sidebar, який об’єднує кілька LLM interfaces і передає їм виділений на сторінці текст або HTML fragment. Для automation engineer це скорочує шлях від inspect element до prompt: можна вибрати DOM block і попросити запропонувати locator або page object. Це не замінює перевірку selector-а. Згенерований варіант треба оцінити за semantics, uniqueness і stability у реальному DOM, але інструмент прибирає кілька механічних copy/paste дій.
Debugger і виправлення помилки в локаторі
Перший запуск падає з `Unable to locate element`: у селекторі переплутано дефіс і underscore. Замість додавання паузи селектор звіряється з уже робочим Page Object, помилка виправляється, а тест повторно запускається в debug mode. На breakpoint можна виконувати код покроково через Step Over або продовжити Resume Program. Це дає змогу побачити, після якої саме браузерної команди змінився стан сторінки, і відокремити помилку локатора від помилки наступного кроку. Після входу додається перевірка success message через `is_displayed()`. Така перевірка корисна як перший експеримент, але ще не робить тест стійким: вона читає стан елемента один раз і не очікує його появи.
AI як помічник для конкретного selector
HTML конкретного елемента можна передати моделі й попросити locator для Playwright або Selenium, уточнивши правила про allowed attributes і partial match. Це швидше за вивчення синтаксису складного XPath, але результат треба перевірити на сторінці. Ще надійніше — мати read access до frontend source, знайти компонент і додати стабільний атрибут у тому самому delivery process.