Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
CSS зручно рухається вниз або між siblings, але в показаному сценарії не дає зручного способу піднятися до parent або далекого ancestor. XPath дозволяє знайти стабільний label, перейти до `parent` або вибрати `ancestor` з потрібним `id`, а вже в його межах знайти input. У фінальному прикладі так знаходиться hidden token input, після чого Selenide `getValue()` зчитує значення його `value` attribute.
CSS-селектори залишаються основним варіантом. XPath потрібен у Selenium для окремих випадків пошуку за текстом або зв’язком parent/child, але швидко ускладнюється: видимий текст може бути розбитий між кількома DOM-вузлами. Стійкі `data-testid`, `id` або `name` краще узгодити з frontend-командою, ніж будувати крихкий XPath навколо layout. Це не «деталь тестів», а тестований контракт між UI та автоматизацією. Рекомендований у відео компроміс: Page Object зберігає locator tuples, а спільні `click`/`type` helpers автоматично чекають релевантний стан. Поряд із цим кожен тест повинен відновлювати потрібний стан, бо локальний success не гарантує стабільність у повному suite.
Поле Search Project можна знайти за `id` або `placeholder`. `placeholder` є зрозумілим, але може змінюватися через локалізацію. Класи зазвичай менш стабільні за спеціальний тестовий атрибут. XPath має широкі можливості навігації вгору й вниз по DOM, але часто читається гірше за короткий CSS-локатор. Результати тестів мають швидко розуміти розробники, тому читабельність і спільна командна домовленість важливіші за демонстрацію максимально складного виразу.
Для важливих або частих перевірок радиться розглянути 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.
HTML потрібного елемента можна передати AI-помічнику з проханням запропонувати Playwright-локатор. Це корисно на початку, коли синтаксис CSS, XPath і role-локаторів ще незнайомий. Згенерований код не можна приймати без запуску. AI може запропонувати статичну перевірку або локатор, що знаходить не той вузол. Для UI-тесту зазвичай кращий `expect`, який очікує потрібного стану й дає змістовну помилку. Кожну пропозицію треба перевіряти в DevTools та реальним тестовим прогоном.
Перед першим комітом Git запитує ім’я та email автора. Автор радить не встановлювати ці значення глобально, якщо для особистих і робочих репозиторіїв використовуються різні облікові дані. Після локального коміту проєкт можна опублікувати через Share Project on GitHub, авторизувати PyCharm і створити remote-репозиторій. Коміт і публікація — різні дії: зелений статус файлів показує локальну індексацію/зміни, а наявність remote і push потрібно перевіряти окремо. Підсумкова стратегія локаторів: обирати читабельні атрибути, які команда може контролювати; домовлятися про них з розробниками; accessibility-, CSS- та XPath-підходи використовувати відповідно до реальної розмітки, а не як догму.
Mobile list часто рендерить лише елементи, видимі на screen, тому до п'ятого чи наступного item неможливо звернутися без scroll. Це відрізняється від звичайного HTML, де весь отриманий DOM часто вже доступний driver. Для пошуку радять `accessibilityId`, accessibility label, Android resource ID або content description, а не XPath. Тестувальник може сам додавати ці атрибути в application code і надсилати невеликий PR на review, бо hotfixes та custom components регулярно порушують навіть узгоджений locator guideline.