Я бы в любом случае не стал использовать, чтобы wtf не вызывать у читающего код)

Кончиться не кончатся. но их может стать меньше. Моя персональная гордость как раз в том что за два года работы в том месте и на этом участке (веб и айпад мобайл) хотфиксов по моей вине не было. Зафэйливание спринтов было, отправление фич на доработку было — а вот хотфиксов по вине нашей команды вроде избежал (в одной из версий до меня было шесть) .

Но вот пайплайны тут совершенно ни при чём.

Надо сначала найти тех кто "управляет качеством". Это может быть весьма проблематично.

И в чём-то сложном используются xpath, всё-таки. Длинных css я не припоминаю себя, хотя у всех по-разному.

Это точно) Но хотя бы теоретический))) пока я не понял даже, зачем это в JS может быть полезным,  с фильтрами не понял

Полезность в том, что один и тот же селектор можно применить для поиска внутри элемента или на всей странице. Условный пример:
есть у меня body button, которым я применяю стили ко всем кнопкам на странице, но в определённой ситуации я хочу применить дополнительные стили к кнопкам, которые вот в этом поддереве.

Я разработку фронта только-только начал осваивать, и пока до css не добрался, так что пример из головы буквально. Может быть полезность совсем в других ситуациях проявляется.

рычагов обычно не бывает от слова совсем. только через рефлексию команд, что мол устали? хотите иначе? давайте попробуем изменить.

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

вот именно, поэтому изменение в пайплайнах не изменит количество хотфиксов =)

если критичных багов нет, то нет и хотфиксов.

Я окончательно перестал понимать, в чем вопрос) Наверное, будет лучше, если вы снова его зададите, дав больше вводных.

ну может быть) Я бы тогда скорее другой синтакс сделал.

Есть еще версия, что так было проще сделать (или может быть быстрее) потому что baseElement когда найден - наверное запоминается только поинтер на него, и поддерево нужно еще раз заново считать. А полное дерево уже есть и возможно как-то удачно хэшировано. Хотя чаще полное дерево огромное, а под-дерево очень небольшое. То есть если полный DOM не хэширован, то разница в скорости поиска должна быть довольно значительной не в пользу теперешней имплементации.

Там же сложность O(log(n)). Не такая уж и значительная.

Хотя может и нет. Не смотрел, как браузеры с домом работают. Надо бы.

ну в большом доме $("#id").$("div") - он найдёт вообще все div, а потом будет их по очереди проверять на то, не лежат ли они под #id 🙂. То есть тут уже зависимость от количества div-ов, выше #id, как O(n) :)

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

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

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

Это при условии, что там такая структура данных, которую придётся полностью перебирать. Не уверен, что это так.

может быть, может быть.

А, был ещё третий. Он обнаруживался только при длительном и интенсивном использовании мобильного приложения — надо было его систематически мучить больше 10 минут, причём по определённой системе. И стратегия воспроизведения нашлась не сразу. Первоначально продакт овнер решил что не стоит  искать "призрака", и релизимся так. Потом по жалобам пользователей выделил команде времени на поиск. У меня ушло на это два дня, хотфикс пошёл через неделю.

> это нецелесообразно было бы гонять
для меня это противоречит следующему утверждению " и =финансовый= вес этого бага в проде"

либо вам это важно, либо нет. важно - автомтазируешь, нет - не автоматизируешь =)

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

вообще, не помню что бы тестирование, а уж тем более автотесты гарантировали "отсутсвие багов".