Комментарии 28
Я бы добавил поведенческий совет Test Automation инженерам. Сразу же постарайтесь заручиться поддержкой фронтендеров. Дружите с ними, наладьте связи, покажите им, как вы выбираете элементы. Возможно начните разбираться во фронтовых фреймворках сами.
Ваши селекторы должны быть независимы от деталей реализации и быть максимально семантичными. От того, что кто-то изменил html-структуру на странице, сделал div-в span’ами и перешёл с bootstrap на что-то другое - ваши тесты не должны упасть. А поэтому вы будете часто просить у фронтов добавить атрибуты типа role, title, is, name, data-testid.
По поводу начала статьи и того, что русский текст в локаторах плох. Я считаю, что русский текст это совсем не страшно, если локатор уникален и нет риска выбрать что-то лишнее. С русским текстом могут возникнуть другие проблемы:
в сайтах с интернационализацией он может зависеть от языка. в этих случаях неплохо бы иметь идентификатор i18n сообщения
Дизайнеры и PO частенько играют с текстом, чтобы угодить пользователю. Будьте готовы к тому, что он будет переформулирован, внутри него выделят какие-то слова жирным шрифтом и пр.
Да, в этом тоже есть смысл, но я больше про русский текст в атрибутах. Например, тот же Protractor позволяет искать по тексту в локаторе с помощью element(by.cssContainingText(element, text)), в таких случаях без русского никуда :)
Но замечание огонь! 🔥
.btn = [class*=”btn”]Хочу заметить, что это не совсем корректно. Селектор [class*=”btn”] сработает, например, на
<button class="btn-primary">, а .btn — нет.Но существует селектор атрибутов с ~=, который работает именно так, как селектор с точкой, но для любых атрибутов, а не только классов: трактует атрибут, как набор слов, разделенных пробелами. То есть,
.btn = [class~="btn"].В XPath очень всего этого не хватает.
Полностью согласен с замечанием, что сопоставлять *= и точку -- нельзя, но это было сделано для наглядности. Мол, локатор можно записать и так, и так, а именно: .btn или [class*="btn"] (с оговоркой, что предпочтительнее использовать сокращенную форму)
Статья пишется для новичков, поэтому "для наглядности" здесь неуместно. Тем более что мощь css селекторов именно в классах, то есть в восприятии атрибута class не как текстового аторибута, а как набора значений. А здесь Вы ставите в ряд обращение к классу как к набору (через точку) и как к обычному тексту, через contains (*).
Кстати, насчет локатор/селектор. Слово "локатор" пришло из селениума и там оно обозначает механизм или реализацию алгоритма поиска (это как название класса printer который умеет что-то печатать). Этот алгоритм уже в свою очередь использует xpath, css селекторы которые по сути просто представлены в виде строк. При желании, например, можно создать свой класс-локатор, который сможет искать элемент сначала по css селектору, а внутри него уже по xpath: By.cssXpath(cssParent, xpathChild). Другими словами, локатор - тот, кто умеет искать, селектор - тот, с помощью которого ищут.
Также в документации по css нет такого термина как "локатор" и для сторфронт разработчиков это слово малознакомо. Поэтому в контексте данной статьи все-таки правильно говорить "селекторы"
Частенько хочется селектор, который бы выбирал, скажем, ссылку по тексту внутри неё. Причём мне не интересно, какое устройство будет иметь этот текст - может быть будет кучей span’ов со сложным форматированием, а может просто текстом. В js я бы просто спросил у ссылки ее innerText. Как такое принято делать в мире qa?
Быстродействие CSS, на сколько я знаю, скорее связано с тем, что не надо тянуть весь DOM, как в случае с XPath (я могу ошибаться). И в единичном случае разница незначительна, но когда нужно ранить очень много тестов на что-то да повлияет.
Не всегда локатор обязан указывать на один элемент. Иногда по локатору нужно тянуть массив элементов.
Раньше сталкивался с массивами локаторов, но понял, что проще найти один уникальный с помощью XPath (если не получается с помощью CSS), всегда найдется что-то, за что можно зацепиться. Но да, согласен, массивы локаторов можно обрабатывать, но на практике встречал пару-тройку раз в виде исключения, поэтому не рассматривал этот подход в статье
А про XPath не знал, если это так, то звучит логично на самом деле 👍
Имхо, не очень понятно, почему сделан такой вывод, что в тестах лучше использовать css.
Основные плюсы (продублирую часть таблицы) -- он простой, краткий, человекопонятный и его +- знают больше, чем XPath. Также я понимаю, что не везде можно применить CSS, поэтому смело можно и нужно использовать XPath.
Ну по поводу "человекопонятный" спорно, на мой взгляд. Тем не менее xpath более распространен в автоматизации - тоже ведь не так просто, как мне кажется. Как более универсальный.
В автоматизации работаю уже 5 лет, был на разных проектах, на всех одинаково плевались на XPath за счёт его громоздкости :) Говорю не только своё мнение, а исходя из опыта своего и других ребят. В статье не было умысла убедить не использовать XPath, лишь рассмотреть, когда он реально может пригодиться, если с помощью CSS никак.
Если одному локатору будут соответствовать несколько элементов, то тест или будет взаимодействовать с первым из них, или просто упадёт с ошибкой
Зависит сугубо от тестируемого сценария и реализации проверки. Если нужно посчитать количество однотипных элементов на странице, то почему бы и нет?
Интересная статья. Спасибо.
Спасибо за статью! Конечно, без практики это просто интересное чтиво. Обязательно доберусь до e2e тестов на проекте, и сразу же достану статью из закладок :).
Спасибо :) В автоматизации есть 2 важных этапа: научиться искать локаторы и применять их в сценариях. Есть отличная практика. Заходим на любой сайт, например, DNS, Epic games и т.д. Придумываем тест-кейс, например:
1. Открыть страницу
2. Ввести в поле поиска название товара
3. Нажать на название товара
4. Убедиться, что отображается кнопка Купить
После этого понимаем, что нам нужно найти локаторы поля поиска, товара, кнопки Купить. Комбинируем варианты с CSS (если локатор простой), если нужно завязаться на текст, то тогда с помощью XPath. В общем, удачи! Если будут вопросы, то обращайтесь в ЛС ;)
Спасибо за статью. Очень доходчиво и понятно. Осталось все проработать и закрепить на практике.
Не согласен с утверждением про Xpath и его громоздкость. Как правило проблема либо в нахождении короткого локатора, либо в фронтендерах...
Для динамического построения и поиска локаторов - без xpath никак, для оперирования с селектами - без xpath никак, для условий contains/not contains/and/or/length и т.д. - без xpath никак.
Исходя из 5 лет опыта. По работе с вебом - только в 1-2 случаях из десяти есть корректные id и классы, к которым красиво можно привязаться по CSS. Остальное - поиск по xpath сверху до низу по соседям/наследникам/родителям и применение условных операторов внутри локаторов.
На мой взгляд стоить изучать xpath - это сложнее для новичков, это не так красиво как структура .class - но профита от этого больше, в том числе и для понимания расположения и работы с элементами на страницах + универсальность и мощное преимущество в виде встроенных функций.
А CSS локаторы использовать только в качестве красивых примеров на шаблонных проектах, ну или в статьях на хабре_)
По работе с вебом - только в 1-2 случаях из десяти есть корректные id и классы, к которым красиво можно привязаться по CSS
Это действительно так, и если речь идёт о работе в одной и той же организации, гордиться тут нечем, надо идти и налаживать коммуникацию с товарищами, которые выкатывают код, не думая о том как он будет теститься. Иначе – каждое техническое изменение в структуре сайта будет ломать наши тесты, а наши тесты должны ломаться когда мы наблюдаем не то поведение, что ожидали.
CSS и XPath для QA: чтобы разобраться с локаторами, нужно всего лишь…