Практичний вибір Playwright locators: accessibility-first пошук, контроль локалізації та A/B experiments, підтримка `data-testid`, читабельний CSS як fallback і відмова від крихких XPath та індексів.
Примітка: конспект укладено за автоматичними українськими субтитрами; технічні терміни нормалізовано за контекстом відео.
Після цього уроку ви зможете
Обрати locator за стабільністю product contract, а не за довжиною syntax.
Зробити A/B variant детермінованим до пошуку selector.
Пояснити команді, коли потрібен test id або accessibility fix.
getByRole спирається на роль і accessible name з accessibility tree. Інші user-facing locators — getByLabel, getByText, getByPlaceholder, getByAltText і getByTitle — шукають за відповідним видимим або описовим значенням. Усі вони читаються ближче до наміру користувача й роблять failure зрозумілішим для розробників — основної аудиторії результатів автотестів. Незначна різниця в швидкості locator неважлива порівняно з network та application latency.
Термін
user-facing locator
Locator, який знаходить element за роллю, accessible name, label, placeholder, text або іншим значенням, доступним користувачеві.
Chrome DevTools дозволяє подивитися accessibility tree й accessible name, навіть якщо значення неочевидне з HTML. Текстові locators зручні, доки labels, placeholders і переклади стабільні. Для багатомовного продукту або content, який окремо змінює контент-команда, стабільний data-testid часто кращий. Атрибути можуть рендеритися по-різному залежно від frontend framework, а generated classes та IDs змінюватися між builds, тому вибір залежить від реального контракту команди.
B2C UI регулярно змінюється через experiments, feature flags і runtime configuration. Якщо тест не контролює variant через cookie, local storage, seed або інший узгоджений механізм, він може випадково бачити різні версії інтерфейсу й падати лише в частині запусків. Спочатку треба зробити variant детермінованим, а не перебирати дедалі складніші selectors.
Глибокі XPath не дають переваги в Playwright: потрібні parent/child operations уже є в locator API, а важливішу бізнес-логіку часто краще перевіряти нижче за UI. Команда автоматизації має домовитися з frontend developers про підтримку test attributes і, за можливості, додавати їх через звичайний pull request. Для публічного production DOM слід окремо оцінити, чи не спрощують описові IDs scraping або розкриття внутрішньої структури.
Якщо стабільного test ID або accessible name немає, припустимий короткий CSS selector через зрозумілий parent і тип дочірнього елемента. Locator повинен читатися; складний вираз варто сховати за змінною з предметною назвою. Не слід використовувати generated hashes, випадкові class names, positional indexes або повні DOM paths. Якщо ID має стабільний префікс і випадковий suffix, можна шукати за контрольованим частковим збігом.
HTML конкретного елемента можна передати моделі й попросити locator для Playwright або Selenium, уточнивши правила про allowed attributes і partial match. Це швидше за вивчення синтаксису складного XPath, але результат треба перевірити на сторінці. Ще надійніше — мати read access до frontend source, знайти компонент і додати стабільний атрибут у тому самому delivery process.