Хороший локатор описывает элемент так, как его видит пользователь или как его стабильно обозначила команда: роль кнопки, имя поля, label, доступное имя, текст, `data-testid`. Плохой локатор зависит от случайной структуры DOM: длинный CSS-путь, порядковый номер `nth-child`, временный класс из сборщика или текст, который часто меняется.
В Playwright и похожих инструментах обычно сначала выбирают локаторы по роли и имени: например, кнопка “Сохранить” или поле с label “Email”. Это делает тест ближе к реальному пользовательскому сценарию и одновременно улучшает доступность интерфейса. Если элемент нельзя надежно найти по роли или label, добавляют явный `data-testid`.
Локаторы напрямую влияют на стабильность тестов. Один и тот же сценарий может быть полезным regression-тестом или вечным источником flaky-падений только из-за того, что элемент ищут по хрупкому селектору. Поэтому локаторы лучше проектировать вместе с UI, а не чинить после каждого редизайна.
Для AI-агентов, которые работают с браузером или computer use, локаторы тоже важны. Агенту проще безопасно нажимать на нужные элементы, если интерфейс имеет понятные роли, labels, уникальные test id и предсказуемые состояния. Это снижает риск, что агент нажмет не ту кнопку или пропустит важный confirm.
Примеры
- Хороший локатор: найти кнопку по роли `button` и имени “Сохранить”, потому что так ее видит пользователь.
- Хороший локатор: найти поле ввода по label “Email”, а не по CSS-классу, который может измениться после сборки.
- Хороший запасной вариант: `data-testid=\"checkout-submit\"`, если у элемента нет стабильного текста или label.
- Плохой локатор: `.page > div:nth-child(3) > button:nth-child(2)`, потому что он сломается от любой перестановки верстки.
- Плохой локатор: селектор по auto-generated классу вроде `.css-1a2b3c`, если класс генерируется UI-библиотекой.
- Для таблицы лучше искать строку по тексту заказа или `data-testid`, а не просто брать “третью строку”, если сортировка может измениться.
Где используется
- E2E-тесты интерфейса: клик по кнопкам, заполнение форм, проверка ошибок и успешных состояний.
- Регрессионные тесты после релизов, редизайна, изменения UI-библиотеки или миграции фронтенда.
- Снижение flaky-тестов за счет отказа от хрупких CSS-путей и случайных порядковых индексов.
- Проектирование `data-testid` для ключевых действий: оплата, отправка формы, удаление, подтверждение, переход между шагами.
- AI browser-агенты и computer use: более безопасная навигация по интерфейсу через роли, labels и стабильные идентификаторы.
- Code review автотестов: проверка, что тесты ищут элементы устойчиво и не привязаны к внутренней верстке.
- Документирование UI-контрактов между QA и фронтенд-командой.
- Связка с evals: проверка, что агент в браузере выполняет сценарий стабильно и не путает элементы.
Связанные термины
Частые вопросы
Что такое локатор в автотесте простыми словами?
Это правило, по которому тест находит нужный элемент на странице: например, кнопку “Сохранить”, поле “Email” или элемент с `data-testid`. Без локатора тест не знает, с чем взаимодействовать.
Какие локаторы самые надежные?
Обычно самые надежные — по роли и доступному имени, label поля, явному `data-testid` или стабильному уникальному тексту. Хрупкие CSS-пути, `nth-child` и auto-generated классы лучше использовать только в крайнем случае.
Когда нужен data-testid?
`data-testid` нужен, когда элемент нельзя надежно найти по роли, label или понятному тексту. Например, у иконки-кнопки, строки таблицы, карточки, скрытого control или элемента с динамическим содержимым.
Почему автотесты падают из-за локаторов?
Если локатор зависит от структуры DOM, случайного класса или порядка элементов, любое изменение верстки ломает тест, даже если функциональность работает. Такие падения часто называют flaky, потому что они не всегда отражают реальный баг.
Чем локатор отличается от CSS-селектора?
CSS-селектор — это один из способов найти элемент. Локатор шире: он может искать по роли, label, тексту, test id, XPath или CSS. В современных автотестах лучше начинать с пользовательских и семантических локаторов.
Как локаторы помогают AI-агентам?
Если UI имеет понятные роли, labels и test id, browser-агенту легче понять, куда нажимать и что проверять. Это снижает риск случайного клика и делает сценарии воспроизводимыми.
