Locator за роллю й accessible name
Locator описує кнопку так, як її знаходить користувач через accessibility semantics.
Playwright знаходить одну кнопку Submit і натискає її.
Пріоритети селекторів та їхня надійність →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Playwright MCP
MCP server від Microsoft, який надає coding agent browser automation через structured accessibility snapshots.
Playwright MCP, CLI, Codegen та AI в розробці →XCUIAutomation / XCTest UI tests
Apple UI automation framework, інтегрований із XCTest, що взаємодіє із застосунком через accessibility information і дозволяє знаходити UI elements, виконувати actions та перевіряти state.
Типи мобільних застосунків та мобільна автоматизація →Вибір mobile automation strategy
Оберіть один власний mobile flow і визначте, що має перевірятися на backend, native component та system E2E levels.
Складіть мінімальну device matrix із поясненням кожного device та OS version.
Назвіть accessibility attributes, яких бракує для стабільних selectors.
Односторінкова strategy з test levels, device matrix і переліком testability changes.
Замінити крихкий локатор на user-facing locator
Знайдіть у власному тесті інтерактивний елемент, який зараз шукається за CSS-класом або вкладеною структурою.
Перевірте його role та accessible name у Accessibility Tree.
Замініть локатор на get_by_role(..., name=...) і запустіть цільовий тест.
Локатор однозначно знаходить потрібний елемент, а тест проходить без nth(), first або прив’язки до CSS оформлення.
Застереження
Назва cross-platform stack не визначає test strategy автоматично. Перед вибором framework потрібен короткий proof of concept на accessibility tree, critical flow і цільових devices.
Типи мобільних застосунків та мобільна автоматизація →WebView, rendering і accessibility
WebView може мати доступ до native navigation, Bluetooth, secure storage та інших можливостей через інтеграційний шар. Водночас Flutter/React Native rendering і custom components створюють окремі ризики для accessibility та поведінки на різних пристроях. Найпростіша практична accessibility-перевірка — збільшити системний font size й переконатися, що текст не виходить за кнопки, поля та контейнери, а елементи залишаються клікабельними. Також згадуються contrast, tactile feedback і безпечна animation, але детальний аудит цих стандартів винесено за межі відео.
Accessibility tree та role-локатори
Accessibility tree показує інтерфейс так, як його сприймають assistive technologies: ролі `link`, `button`, `textbox`, `searchbox`, `list` та їхні доступні імена. У DevTools потрібно ввімкнути повне accessibility tree й перезавантажити сторінку. Playwright підтримує локатори на основі цієї семантики, наприклад `get_by_role`. Вони часто добре читаються та водночас перевіряють, що елемент має зрозумілу роль. Але на проєкті все одно потрібна єдина домовленість про основну стратегію та допустимі винятки.
Accessibility tree, локалізація і стабільність атрибутів
Chrome DevTools дозволяє подивитися accessibility tree й accessible name, навіть якщо значення неочевидне з HTML. Текстові locators зручні, доки labels, placeholders і переклади стабільні. Для багатомовного продукту або content, який окремо змінює контент-команда, стабільний `data-testid` часто кращий. Атрибути можуть рендеритися по-різному залежно від frontend framework, а generated classes та IDs змінюватися між builds, тому вибір залежить від реального контракту команди.
Чому Playwright радить `getByRole`
`getByRole` спирається на роль і accessible name з accessibility tree. Інші user-facing locators — `getByLabel`, `getByText`, `getByPlaceholder`, `getByAltText` і `getByTitle` — шукають за відповідним видимим або описовим значенням. Усі вони читаються ближче до наміру користувача й роблять failure зрозумілішим для розробників — основної аудиторії результатів автотестів. Незначна різниця в швидкості locator неважлива порівняно з network та application latency.
Platform guidelines, native, web і hybrid
iOS Human Interface Guidelines і Android Material guidelines задають expected platform behavior. Тестування має враховувати, що calendar, navigation, gestures і accessibility відрізняються між platforms. Мобільний product може бути responsive web, native, hybrid WebView або cross-platform. Hybrid app має native shell і web context, тому автоматизація має розуміти context switching й не трактувати все як однакову UI tree.
Локатори й доступність у реальному інтерфейсі
Під час пошуку елементів для наступного тесту видно, наскільки якість HTML впливає на автоматизацію. У модальному вікні частина елементів не має зручних семантичних ознак, стабільних назв або доступних ролей. Через це доводиться розглядати `id`, текст, структуру `div` і Accessibility Tree. Кращий локатор спирається на доступну роль, ім’я або іншу стабільну продуктову ознаку. CSS-класи оформлення, випадкові вкладені контейнери й пробіли в тексті — крихка основа. Якщо елемент важко однозначно знайти, це може бути не лише проблемою тесту, а й сигналом недостатньої доступності чи тестованості інтерфейсу. Після дослідження обирається невеликий реальний сценарій: створити сутність через кнопку, заповнити назву й перевірити наступний стан. Саме повторювані частини цього сценарію далі перетворюються на live templates.
Testability і readable feedback
Mobile platforms обмежують custom attributes сильніше, ніж web. Тому testability будується разом із developers через accessibility identifiers/semantics і stable component contracts. Test report має бути зрозумілим розробнику: scenario, platform/device, build, request/response де доречно, screenshot/log і failure boundary. Швидкий feedback важливіший за кількість scripts.
Scroll, virtualized lists і locator contracts
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.
Native tests і внесок у testability
Для важливих або частих перевірок радиться розглянути 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.
Семантичний локатор поля пошуку
Поле пошуку знаходиться через `get_by_role("searchbox", name="Search")`. Такий локатор спирається на доступну роль і назву елемента, тому краще відображає намір користувача, ніж випадковий CSS-клас. Перед заповненням поля перевіряється `to_be_visible()`. Назва цільового проєкту зберігається у змінній, бо це одне й те саме предметне значення для введення та подальшого очікування.