Отправлено автор:
В топике речь о функциональном UI тестировании, поэтому fuzzy "за бортом".
А можно пример, когда нельзя однозначно определить элемент по локатору, а итерации среди кандидатов могут?
Я могу привести пример. A/B тестирование, например.
Если вы не можете повлиять на то, в какую фокус-группу попадает ваш тестовый пользователь, то вам нужно добавлять ветвление в тест (тесткейс / зависимый тест / или как вы их там группируете).
Вы наверное не то сообщение процитировали, так как вопрос про итерации, а ответ про ветвление.
В случае А/В безусловно будут иметь место всяческие ухищрения (альтернативные локаторы/сценарии) - много чего можно наворотить, но не в виде
public void test(){ if (element1.exist()){ button1.click(); }else{ button2.click() } }
вроде бы, то процитировал, что хотел.
1) Простите, но итерации без условия - вечный цикл.
2) Про циклы. Например, представим себе задание на тест, чтобы тест в рамках одной сессии прокликивал все варианты цен где-нибудь. Например, цены подписки на месяц, полгода, года, десять лет на какой-нибудь журнал и проверял, что цена подписки вычисляется правильно и т.п.
Вы можете сказать: "хха, тут нужно использовать датапровайдеры!", на что я вам отвечу: "хха, датапровайдеры не всегда можно использовать, если добрать до какого-нибудь раздела занимает, например, 40 секунд (тестом), а прокликать все варианты цен - десять.
Вы (я предполагаю, что вы так предложите), заявите: ну и что. Я их распараллелю и все тесты будут проходить в 45 секунд, просто в пять потоков. А я вам отвечу: а что если задача сложнее? если я не могу параллелить именно этот тест? Например, потому, что именно при переключении с одного периода подписки на другой уже неоднократно находили ошибку?
Мне кажется, вы слишком категорично говорите о том, что "нельзя использовать циклы и условия!!"
а тот тест, который вы привели - да, это глупо. Но если залезть дальше такого примитивного теста (например, в интеграционные тесты) - там не обойтись без условий.
