зачем промежуточные долгие бесполезные дискуссии

звучит как блокчейн

К сожалению реклама

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

🙈

Хочу перехватывать всплывающие ошибки. Чтобы убедиться, что она, действительно, всплывает - использую shouldHave(text()). А вот, если у меня несколько вариаций ошибок (они могут меняться) на одно и тоже действие, как это лучше фиксировать? Можно ли результат shouldHave записать в переменную, а потом применить логическое or? В какую сторону читать/смотреть?

в смысле в одном сценарии могут выскочить разные ошибки, и это нормально?

Так не стоит делать. Вы чётко должны знать что за ошибка у вас, если вы хотите именно ошибку проверить.
Или у вас задача "пофиг на ошибку, идём дальше"?

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

Тогда нужно приводить систему в нужное состояние.

Согласен, что это не очень. При первом запуске теста мне система говорит, что пароль не верен (так и должно быть). При повторном запуске, меня просят подтвердить, что я не робот. Тест падает, соответственно.

Капча? Если v2 и ваш сайт, можно отключить.

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

Не, сайт не мой. Но я понял, примерно, спасибо

Можно фиксировать то что есть ошибка и её текст, если так будет лучше.

Вот, кстати, красивое решение просто фиксировать факт появления ошибки. До этого делал проверку по точному тексту. Благодарю!

Выглядит, как будто вы не можете воссоздать желаемый контекст для теста и поэтому не можете сформировать правильное критерии корректной реакции системы на ваши действия. Так как коды ответов и их тексты достаточно важный механизм взаимодействия, я бы предложил не опираться на факты появления «любой» ошибки и попробовать привести систему в контролируемое состояние. Если мешает капча — отключить, если нужно проверить на капчу — в 10/10 раз научиться ее вызывать.

есть такие варианты:

1. переделать тесты так, чтобы один тест тестировал только первый логин, а второй - только повторный логин. Остальные тесты (наверняка им тоже нужен логин) - делать как первый или как второй вначале.

2. если проверяется один и тот же элемент, то использовать *or* condition в Selenide element.should(or("robot check or wrong pwd", text("robot"),text"(wrong pwd"));

3. (так себе) если проверяются разные элементы:  ловить AssertionErrors и внутри костылить обработку.

Круто! Пойду вот эту конструкцию изучать element.should(or Благодарю!

Спасибо, да, просто интересен был сам факт, что вообще в подобных ситуациях я могу сделать, ибо наткнулся вчера, а тесты падают