Забудь про XPath и CSS-селекторы: путь от стандартных локаторов к кастомным

[teka_d]

Можно фильтровать кастомные локаторы на этапе сборки, используя переменные окружения. Например, в React-приложении функция для добавления локатора может выглядеть так:

export function locator(name?: string, type?: string, value?: string, state?: string) {
  if (process.env.APP_ENV === 'production') {
    return {};  // На проде возвращаем пустой объект (локаторы не добавляются)
  }
  return { 'data-n': name, 'data-t': type, 'data-v': value, 'data-s': state };
}

Примеры использования:

<button {...locator('wat-login-button', 'primary')} />

• В development-среде кнопка получит атрибуты:

  <button data-n="wat-login-button" data-t="primary"></button>

• В production-среде атрибуты добавляться не будут:

  <button></button>

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

[mihmig]

Разработчики одного из банков не стали заморачиваться с удалением тестовых тегов на "проде":

[egribanov]

А смысл? Ну есть они и есть, максимум если только с какими нибудь парсерами бороться, но есть ли смысл?

[grg2000]

Интересно, а можно узнать подробнее каким образом реализуется удаление кастомных локаторов на проде?

[RealLazyCat]

технически это просто:
есть коммит разработки.
добавляют тест-локаторы.
делают коммит
раскатывают и тестируют на тест -стенде
откатывают коммит
раскатывают на проде
или вообще добавляют в отдельной ветке локаторы. которую потом удаляют

но вот процесс вставки тест-локаторов интересен, не руками же их вставляют

[grg2000]

Звучит заморочно, и как будто бы такие локаторы будут каждый раз теряться при релизе, либо в через определенное время придется при релизах кучу тестовых комитов откатывать. В общем интересно как у автора это на проекте реализовано.

Когда я сталкивался с аналогичными решениями - приходилось самим ходить во фронтовый код и вставлять локаторы, потом скриптом парсили их все сразу в проект теста.

[teka_d]

Можно фильтровать кастомные локаторы на этапе сборки, используя переменные окружения. Например, в React-приложении функция для добавления локатора может выглядеть так:

export function locator(name?: string, type?: string, value?: string, state?: string) {
  if (process.env.APP_ENV === 'production') {
    return {};  // На проде возвращаем пустой объект (локаторы не добавляются)
  }
  return { 'data-n': name, 'data-t': type, 'data-v': value, 'data-s': state };
}

Примеры использования:

<button {...locator('wat-login-button', 'primary')} />

• В development-среде кнопка получит атрибуты:

  <button data-n="wat-login-button" data-t="primary"></button>

• В production-среде атрибуты добавляться не будут:

  <button></button>

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

[rsashka]

Некоторые веб-приложения создают динамические идентификаторы для элементов, которые изменяются при каждом обновлении страницы. В таких случаях традиционные селекторы становятся бесполезными, так как невозможно точно указать элемент по его id или классу и остается полагаться только на XPath.

Вот в этом и состоит корень зла. А ваше решение, это фактически возврат к нормальным XPath и СSS-селекторами, как они задумывались изначально.

[teka_d]

Раньше тоже так думал, потом пообщался с коллегами из других компаний, оказалось, что не всем это очевидно. Что уж там, сам я тоже когда-то пользовался исключительно селекторами, созданными разработчиками. Потому решил, что тема все ещё может быть актуальна.