Писали ли вы селекторы?

Что проверяют

Умеете ли вы писать локаторы, которые переживают редизайн, или ваши тесты краснеют после каждой правки вёрстки. Это самый частый источник нестабильных автотестов, и по ответу видно, занимались ли вы поддержкой набора, а не только его написанием.

Как отвечать

Опишите свой порядок выбора, от самого устойчивого к самому хрупкому:

• специальный атрибут для тестов, например data-testid, добавленный разработчиками по договорённости;
• роль элемента и его доступное имя: кнопка с определённым текстом, поле с подписью, это заодно проверяет доступность интерфейса;
• устойчивый идентификатор или атрибут, который несёт смысл, а не оформление;
• CSS-селектор по осмысленным классам и атрибутам;
• XPath, когда нужен переход к родителю или поиск по тексту, но короткий и от ближайшего опорного узла.

Скажите, что локаторы живут не в теле теста, а в объектах страниц, чтобы правка была в одном месте. Упомяните ожидания: элемент ищется с ожиданием появления и готовности, фиксированные паузы это заявка на мигающую проверку. Полезно назвать особые случаи: iframe требует переключения контекста, а закрытый теневой DOM обычным селектором насквозь не пробивается.

Где спотыкаются

Берут XPath, скопированный из панели разработчика. Абсолютный путь через десяток узлов ломается от любой новой обёртки, а обращение по номеру потомка перестаёт работать, как только в списке меняется порядок.

Второе: цепляются за сгенерированные имена классов. Хэш в имени меняется при каждой пересборке стилей, и тест падает не от дефекта продукта, а от того, что фронтенд собрали заново.

Третье: ищут элемент по видимому тексту в двуязычном интерфейсе. При переключении языка набор рассыпается целиком, поэтому текст годится для проверки результата, а для поиска элемента лучше атрибут.