Если это по какой-то причине критично, то можешь завести Issue в support.qameta.io и мы поможем найти workaround

@eroshenkoam Добрый день, а можно ли у автоматических тестов проставлять Precondition и Expected results

из allure

Всем привет! Немного не в кассу, но нужна помощь…
Часто слышу холевары на тему использования правильных тестовых элементов в DOM-модели, и взаимодейтсвия с фронт разработчиками по созданию таких элементов. Сейчас столкнулся с ситуацией, когда фронт разработчики сообщили, что тестовые атрибуты, это антипаттерн и вообще зло )
пока аргументов не получил, встреча будет завтра.
Собираю аргументы в пользу использования тестовых аргументов. Что есть:
1) Не на что не влиях/никому не мешают, если создаются уникальными
2) В части безопасности не вижу проблем
3) Используют крупные компании, такие как facebook
Какие мысли из минусов
1) Усложняют чтение по DOM модели - больше текста
2) Дополнительная нагрузка на сеть
Может быть у кого-то есть мысли или опыт, почему это антипаттерн и чем аргументировать внедрение тестовых атрибутов?

что такое тестовые атрибуты? id для элемента это не тестовый атрибут 🙂

если же речь о том, чтоб добавить элементу что-то типа selenium-id=id_for_test то конечно это антипаттерн, потому что код должен быть чистым)

т.е. единственный аргумент в том, что появляется лишний код?

интересует моменты в части
1) влияние на безопасность
2) нагрузка на сеть
3) может быть что-то еще, пока думаю )

Его достаточно.. есть же нормальные общеиспользуемые атрибуты id (но я вижу что он там сгенерен, ага, как в ExtJS прям) или, например, name (на скриншоте он кое-где есть)

это пример из facebook-а )
не понял про id. В моём понимании чистый код, если грубо, это код без всего лишнего, а получается мы, заменяем один атрибут на другой )
P.S. id нам может подойти так как у нас в системе он, почти не используется

Ну id полезен для всяких там ещё Яндекс метрик )

Так что за него агитировать проще чем за что-то своё чисто для тестов

хм, круто, согласен. Хороший будет аргумент для нас. Спасибо за идею )

Тоже суну свой нос, т.к. интересен результат борьбы.
Со своей стороны могу сказать, что проблема единственная - нехватка времени у фронтендера на занос таких ID, поэтому делали точечно для "критично-неудобных" и только для дев/тест стенда. В прод оно не уходило - мусор.
В части безопасности - не вижу никаких проблем. Эти id даются тупо наружу, что по ним можно сделать нехорошего (свыше того, что можно и без них) лично мне сложно представить.

Максим, спасибо за помощь. В группе  “Selenide на русском” много дельных соваетов дали, если интересно, советую посмотеть )
Относительно выделения времени на тест-айди, пошли другим потём, через требования с использованием definition of done и чек листа - условия, при которых задача будет закрыта - ревью, создание data-testid, автотесты и тд

Почему это антипатерн?

Html это разметка, а не код, это никак не повлияет ни на что кроме упрощения работы граберов и ботов

Использовать data-qa атрибуты это топ, оно никак не ломает вёрстку и супер упрощает написание е2е тестов

Потому что те кто его не используют топят против всего нового :)