Comments 6
11 хорошая практика написания тестов на Selenium - переходите на Playwright
Моё мнение что при использовании селекторов они должны быть сделаны в едином стиле.
Либо во всех местах id и name, либо css, либо везде xpath.
А если смешивать, то тесты становятся плохо читаемы. Касательно быстродействия, то при кликинге различие между типами селекторов не влияет ни на скорость ни на ресурсоемкость, потому что сам клик и отслеживание его реализации на порядок перекрывает поиск селектора.
А если парсить, то selenium используется в связке с angelsharp или agilitypack, дерево dom анализируется один раз для страницы, что ускоряет парсинг на порядок и опять же скорость и ресурсоемкость упирается в количество окон и отслеживание последнего нужного тега на странице, а не в поиск селектора.
Уважаю ваше мнение, но по некоторым моментам могу сказать из практического опыта. Единый стиль селекторов - это практике обычно "nice to have". Поясню.
Приложения могут писаться в течение долгих лет кучей разных людей и даже команд. На практике сложно наладить коммуникацию и внедрение id и name везде, если разработка не затрагивает более старые части приложения. Прямо сегодня они должны (на самом деле нет) писаться с добавлением уникальных идентификаторов, с этим согласен, но на практике я не скажу разработчикам "тут нет айди, иди переделывай", я скорее всего просто использую xpath и подожду, пока этот id там появится. Кроме того, он, в отличие от id, name и CSS, подходит для поиска элементов, которые содержат определенный текст, например, что бывает полезно иногда.
Если тесты становятся плохо читаемы из-за того, что какие-то селекторы меняются, значит надо отделять тесты от селекторов. Сам тест не должен зависеть от селекторов, плюс централизованное их использование позволяет пофиксить кучу тестов иногда просто обновив одну строчку, не трогая код самих тестов при этом.
С динамическими приложениями, в которых элементы генерируются автоматически, номер с id и name очень часто не пройдет, поэтому там проще использовать селектор-генераторы, функции, которые генерируют селекторы на основе xpath-шаблона для элементов определенных типов.
Я бы тоже предпочёл иметь везде id, потому что это не только проще использовать, но и сложнее сломать, но, к сожалению, это не всегда реалистично. XPath сильно гибче, но менее надёжен, если UI в активной разработке. Про CSS, который генерируется автоматом и минимизируется на каждый билд, поэтому меняется полностью каждый билд, вообще молчу. Поэтому временами приходится комбинировать и то, и то, и то, и просто стараться соблюдать баланс между покрытием, стабильностью тестов и удобством поддержки. В любом случае, это всё не для того, чтобы сделать вам приятно, а для того, чтобы бизнес мог решать свои задачи.
По поводу быстродействия полностью согласен. Разница в поиске была заметна во времена древних версий Internet Explorer может быть, ни для одного современного браузерного движка это не проблема, любой простой запрос на бэк + обновление DOM tree обычно занимает дольше.
Я в своей практике вообще только Xpath использую, а все остальное для понимания как рефакторить чужой код. Использую Xpath для того чтобы использовать одну обертку на все действия:)
Почему единый стиль селекторов, потому что сайт к этому располагает, если там есть id и name, то они есть почти для всех задач. Если сделано классами, то опять же любая задача решается через querySelector, а все остальное - это xpath.
Но моя практика специфична, я почти всегда работаю с сайтами где стоят защиты от парсинга.
А как это централизованое использование селекторов по п. 2? Вы их в массив enum вносите?
Зависит от проекта и того, какой подход используется - Application Action или Page Object Model. Можно в Dictionary, можно в отдельный класс Selectors, можно как проперти Page Object, можно enum. Главное, чтобы в самих тестах использовались имена для элементов, с которыми вы работаете, а не селекторы напрямую.
При использовании Application Action может быть проще.
Пример. У меня был случай, когда был набор из нескольких веб-приложений построенных на одной кастомной UI библиотеке с 2-3 разными версиями этой самой библиотеки. Разные тестовые пакеты (один пакет на приложение) включают класс приложения. Класс приложения имеет проперти Locators, это проперти - объект, унаследованный от CommonHelpers.CommonLocators и расширяющий его специфическими для данного приложения локаторами. Объект - потому что туда же можно добавить методы для динамической генерации селекторов, а точные селекторы как проперти. В том случае, если в каком-то приложении селектор отличается от того же в CommonLocators, он просто добавляется в локальный класс Locators через override. Когда тестируемое приложение обновилось до совпадающей с CommonLocators версии UI библиотеки, локальные селекторы просто удаляются из локального класса селекторов и автоматически за счет наследования используются общие селекторы.
Для поиска одинаковых селекторов можно написать скрипт, который тупо пройдет по CommonLocators и всем классам для отдельных приложений, найдет одинаковые/разные селекторы и выдаст вам список того, что можно удалять за ненадобностью и где. Общие селекторы добавлялись после того, как более чем одно из приложений получали одну и ту же версию UI компонентов, остальные догоняют по мере обновления. Тут больше регулярная организационная работа и надо отдельно смотреть в каждом случае, можно ли "автоматизировать автоматизацию" скриптами, но в целом такой подход сильно сократил время на поддержку и дал больше времени на написание новых тестов.
При этом в самих тестах скрипты остаются без изменений месяцами (потому что тестовые сценарии на меняются и используются те же веб-элементы), подавляющая часть локаторов находится в одном файле, соответственно, при обновлении в одном месте они будут использоваться во всех тестовых пакетах, обновление селекторов можно планировать, если есть информация об апдейтах приложений в джире (таск на обновление версий компонентов), классы селекторов для отдельных приложений остаются примерно одного размера, плюс-минус 20 селекторов в разное время, и так далее.
Я в целом тоже предпочитаю XPath, просто стараюсь писать менее хрупкие селекторы по возможности.
На английском оригинальные тексты выглядят нормально, но эти переводы в лоб читать невозможно
10 хороших практик автоматизации на Selenium C#