это ж bdd... всегда было интересно, а кто пишет сам код, который реализуется через user- friendly интерфейс того же rspec?)

Юнит пишут девы, e2e пишут девы и qa, интеграционные частично я писал, частично qa. Что значит user friendly в данном контексте?

просто у нас проект - веб-приложение, которое чем-то напоминает коструктор ПК в том же ситилинке, только в разы сложнее по наполнению/содержанию и с разными базами для разных стран... И вот я пока с трудом себе представляю BDD в подобном проекте - зависимостей слишком много...

Поэтому пока всё в селениуме и xpath... который тоже не сильно оптимален, т.к. у разрабов нагрузка такая, что нормально писать с уникальными ID - времени нет(

Зато как плюс - child/parent в xpath попрактиковал)))

Мммм, IDшники вообще не для этого.
Тренд последних лет использовать data-* html attributes
https://medium.com/@colecodes/test-your-dom-with-data-attributes-44fccc43ed4b

child-элементы кстати можно и для css селекторов прописывать, не только для xpath

у нас мода - менять классы очень часто))) Поэтому xpath)

Мы у себя покрываем только critical path для e2e. Все остальное нет смысла тестить, слишком быстро меняется

у нас тоже меняется часто... но функционала очень много - кликать его долго. Поэтому автотесты)

Так и я выше все про автотесты писал. Вручную только первый релиз фичи тестируется, а дальше она либо в critical path попадает, либо на нее забивают

Посмотрел "HTML-атрибуты data-*" - это ведь нужно, чтобы разрабы писали приложение используя этот тренд... Так-то я в любом случае найду элемент так, или иначе) Весь вопрос во времени)
Как правило, гляда на "Посмотреть код" в Хроме, почти сразу видно, как лучше/проще найти тот или иной элемент)

Да. Но поскольку это независимые аттрибуты, которые используются только для тестов, то их можно впихать в нужные элементы и самому, не рискую нарушить что-то в работе приложения

хм.... но это значит, что нужно "лезть в код" самого приложения?

а почему нет?

Страшно😅😅😅 Плюс, там такая бизнес-логика заложена, что на всём проекте её понимает/знает/помнит/МожетРассказать человека 4... из 10-20 (я точно не знаю). Впрочем, можно попробовать предложить) Попробую завтра...😇

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

Это идеальный вариант для автотестов, но накладывает оверхед на дев команды. Не все согласятся на замедление разработки в плюс автотестерас

Так же есть обратная сторона - такие атрибуты не должны быть на продакшене. Как их вырубать там - отдельная тема, которая тоже требует ресурсы (опять же их не все готовы выделять)

Что плохого если на проде будут?

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

Возможно секьюрность нарушена будет

Как?