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

А вообще, наш спор бессмысленный и мне поэтому крайне лень его продолжать.
Андрей утверждает, что достаточно знаний селенида чтобы начать писать тесты, и я с этим не спорю, это действительно так.
На этапе когда достаточно сделать $(...).shouldBe(...); никаких проблем.
(вот бы все проблемы и задачи автоматизации решались таким образом).
При этом, инструмент отличный, и 90% если не больше задач решает лучше чем селениум, поскольку исчезла масса бойлерплейта и добавились стабильность, удобство, скорость и т.д. Но незнание "предтеч" пользователя серьезно ограничивает, и если проект на котором он работает большой и сложный, это неизбежно скажется.
Я на этом закругляюсь, это исключительно мое мнение которое совершенно не нужно разделять или оспаривать. Пишите как хотите и на чем хотите, я не возражаю :)

Да мнение правильное, что знать "предтечи" полезно. Разве ж с этим кто-нибудь станет спорить?

Исходники джиры в моё понятие "предтеч" не входят, если что :)

Ну это так, лёгкий вброс :)

Вопрос-то был только в том, с чего начинать.

По-моему, это работает так: начинаю с простого, появляется проблема (скажем, с StaleElement в $.exists) - изучаю, дебажу, становлюсь умнее.

И вряд ли это работает так: "Дай-ка я изучу заранее всевозможные предтечи - а вдруг когда-нибудь пригодится".

Что там в "чистом" селениум такого сложного? Он учится за два-три дня.

Мне кажется подобные ошибки человека который привык дергать апи ставят в тупик. Работая с селениумом, она, имхо, выглядит несколько нагляднее.
И "изучаю, дебажу", мне кажется, это не уровень человека который знает только про то, что $(element).shouldBe(visible);

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

Да почему вдруг простота провоцирует? Ну с какой стати? Откуда это взялось?

Получается, нельзя давать первоклассникам простые примеры - они ведь провоцируют уметь решать только простые примеры?

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

Мне кажется сравнение не очень корректное.
Люди просто расслабляются когда у них вся деятельность ограничена 10-20-ю командами типа click() / shouldBe, и начинают себя считать гениями автоматизации которым больше ничего не надо знать - ведь и так все работает.
А потом падают в обморок столкнувшись с какой-то неочевидной проблемой, которая не решается перебором команд описанных выше.
Дебажить, изучать, это постфактум уже..

this.

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

А если внезапно результат надо получить дробью обыкновенной, а не десятичной?))

Да в каком мире вы живёте? Это же совершенно нереально, что даже с селенидом у вас не возникает никаких проблем, и вы спокойно живёте, ни во что не вникая. Ну нет же! Проблемы возникают постоянно, и их приходится изучать постоянно, хочешь или не хочешь. Спокойно прожить просто не получится.

А речь и не о нас, а о тех кто только начинает.

Или, начал уже давно, но в силу вышеописанных причин дальше click() не ушёл.
Новичку (как правило, хоть и не всегда) хочется вложить поменьше усилий и получить "выхлоп" побольше. Селенид ему эти возможности вполне предоставляет: конфиги он где-то стырит, а находить локаторы при наличии id и апи "вслепую" дергать и обезьяна научится, и это до поры до времени будет работать, пока не выяснится что да, надо дебажить, надо изучать, надо всяко разбираться. А потом выясняется что у селенида код под капотом несколько посложнее (или просто иначе устроен) чем у селениума и причинно-следственную связь между ошибкой и решением становится понять значительно сложнее.

Мне вот еще на ум приходит сравнение java и lombok.
Для новичка lombok лютое зло, для человека который более-менее знает java - порой, спасение (особенно до появления record'ов).

Да почему сложнее-то? Ну с какой стати?