Весь пакет Support является опциональным и просто взглядом разработчиков на то какие дополнительные вещи можно делать. ExpectedConditions в C# вообще использовать не стоит и аргументировать ими тоже — они deprecated и были просто пережитком того что в старых версиях Java не было лямбд.
Как по мне — дейтсивтельно лишним является только передача самого объекта IWebDriver внутрь ожидания, особенно если вы пишите какие-то абстрации вокруг драйвера.
Для себя сделал аналогичную реализацию, с немного другими фичами — github.com/MrHant/tiver-fowl.Waiting
Там нет протянутого IWebDriver, добавляется конфигурация, и прозрачное логирование. Так же вам может быть интересно возможность делать «Extended Wait» где проверка сразу не будет отваливаться по таймауту, а подождёт подольше и потом отметит тест как Warning (только для NUnit).
Ибо игрок может загнать игру в такую комбинацию, никакой бот не загонет.
Не в этом ли проблема?
Если очень захотеть и потратить достаточное кол-во времени — можно свести игру к набору действий которые может выполнить игрок — и куда его это может привести. Конечно в результате мы получим полный перебор вариантов развития событий — который даже бот не сможет прогнать за обозримый отрезок времени.
Судя по сообщению сейвы вы выбирали случайным образом, а значит это не даёт вам никакой уверенности в результате. Вы только периодически сокращаете множество ошибок которые могут возникнуть.
Альтернатива полному перебору и случайности есть. Она называется парное тестирование (Pairwise testing). Правда в вашем случае скорее всего набор тест кейсов полученый парным тестированием будет очень велик, но подход всё же есть.
Коротко о парном тестировании — сперва вы определяете набор действий и значений которые может выполнять игрок(бот), далее вы определяете стандартные значения для каждого из действий/значений.
После этого — вы начинаете попарно изменять значения в каждом тесте.
В конкретно вашем случае — тестом будет скорее не прохождение игры от начала до конца, а совершение одного хода игры (если игра пошаговая), с контролем ожидаемого результата на каждом шагу.
То о чем вы говорите является базовыми знаниями в теории функционального тестирования.
По теме — Анализ граничных значений (Boundary Value Analysis) и Эквивалентное разбиение (Equivalence Partitioning).
Использование же случайных значений — так же рассматривается как проблема функционального тестирования, а именно как путь борьбы с «эффектом пестицида». При этом случайные значения беруться только в пределах какого-то из полученных разбиений, а не на всём множестве значений.
В итоге чтобы сделать хорошее автоматизированное тестирование — человеку неплохо бы подтянуть базу по функциональному тестированию.
Так то оно так, вот только не вам это решать. Вы пытаетесь насильно людям навязать своё мнение. Это могло бы сработать будь вы им родитель, старший товарищ или кумир, но вы совершенно чужие люди.
Человек который захотел поставить у себя камеру (даже в профессиональных целях) — не обязательно айтишник. Он поставил камеру и радуется что она приносит пользу — и это профит.
Сколько времени у такого человека займёт выяснение причин — что произошло с камерой? В худшем случае он подумает что она испортилась и купит ещё одну такую же.
Ваш же сценарий исправления ситуации очень радужный. После сброса камеры ему нужно каким-то волшебным образом понять что это было сделано кем-то из вне и закрыть стандартного пользователя. Хотя вы же писали что при этом стираются все логи, т.е. факт доступа из вне не зафиксирован нигде. Я бы скорее в такой ситуации грешил на сбой оборудования, чем на вмешательство 3й стороны.
Я видел некоторые камеры которые были направлены на датчики (вроде бы датчики давления) — это явно какие-то профессиональные вещи с заводов или чего-то похожего, вероятно использующиеся людьми для переодического контроля ситуации на удалённых объектах.
Заблокировав такую камеру вы помешали кому-то работать как минимум. Как максимум человеку придётся срочно собираться в дорогу и разбираться что же стало с его камерой. Ведь камера могла выйти из строя в том числе в случае аварии на объекте.
В любом случае, я спас 1919 камер от любопытных глаз, и это тоже неплохо!
Спас? Вы оставили их владельцев без доступа к камере. Вы не думали что так могли им навредить?
Камеры люди ставят не от хорошей жизни. В труднодоступных местах, тех местах где они редко бывают но за ними нужен присмотр.
это не баг, это фича. и то что вам приходило скорее всего действительно спам.
гмейл не отличает точек в имени.
т.е. ящики equand, e.quand, и даже e.q.u.a.n.d — все ваши. никто не сможет зарегистрировать ящик отличающийся от вашего только точками.
А как при такой схеме вы проводили валидацию исправления дефектов? регрессионное тестирование после?
Или у вас была штатная команда тестировщиков кроме упомянутого конкурса для фрилансеров?
есть и более типичная задача. Вы просто хотите форматированно отображать телефон, с пробелами между кодом страны/города и самим телефоном
и если вы заранее не позаботились о том чтобы у вас в поле телефон был «валидный» телефон — для решения этой задачи вам нужно будет пытаться обработать эти случаи с разбиением запятой, пробелом, «или». а может человек вообще ввёл «нет» в это поле.
Hint:
если бы вы использовали gmail можно было бы обойтись разным количеством точек вместо фильтра
my.any.address@gmail.com — основной
myany.address@gmail.com — важная почта
Что-то в этом духе. Все письма бы всё ещё приходили на ваш ящик, но вы бы смогли фильтровать их по полю To.
ну если делать посимвольно то бред,
А если скажем сгруппировать по странам (коду страны, коду города) то уже можно получить симпатичный такой справочник клиентов
Однотипность данных в системе даже если не используются рассылки — важная вещь
Вдруг вы потом решите добавить сортировку по телефону? или захотите проанализировать каких операторов используют ваши клиенты?
В итоге посыл должен быть другой — используйте регулярки, но вместо того чтобы блокировать регистрацию с «неправильным» адресом — выводите пользователю предупреждение или требуйте подтверждения (на форме) что он всё ввёл корректно.
А не забыли ли вы о пользователях в этой погоне за простотой кода?
Регулярка там или нет — я хочу чтобы в случае опечатки форма мне помогла исправить ошибку до того как уйдёт письмо на несуществующий адрес. Ведь в этом случае мне как минимум придётся заполнять всю форму регистрации заново, и это если я замечу что была опечатка в адресе. А я могу не знать и просто сидеть и ждать когда же мне дойдёт письмо.
Одинакого плохо оставлять и IWebDriver и ISearchContext.
Не всегда Wait будет привязан к поиску чего-то.
Как по мне — дейтсивтельно лишним является только передача самого объекта IWebDriver внутрь ожидания, особенно если вы пишите какие-то абстрации вокруг драйвера.
Для себя сделал аналогичную реализацию, с немного другими фичами — github.com/MrHant/tiver-fowl.Waiting
Там нет протянутого IWebDriver, добавляется конфигурация, и прозрачное логирование. Так же вам может быть интересно возможность делать «Extended Wait» где проверка сразу не будет отваливаться по таймауту, а подождёт подольше и потом отметит тест как Warning (только для NUnit).
Не в этом ли проблема?
Если очень захотеть и потратить достаточное кол-во времени — можно свести игру к набору действий которые может выполнить игрок — и куда его это может привести. Конечно в результате мы получим полный перебор вариантов развития событий — который даже бот не сможет прогнать за обозримый отрезок времени.
Судя по сообщению сейвы вы выбирали случайным образом, а значит это не даёт вам никакой уверенности в результате. Вы только периодически сокращаете множество ошибок которые могут возникнуть.
Альтернатива полному перебору и случайности есть. Она называется парное тестирование (Pairwise testing). Правда в вашем случае скорее всего набор тест кейсов полученый парным тестированием будет очень велик, но подход всё же есть.
Коротко о парном тестировании — сперва вы определяете набор действий и значений которые может выполнять игрок(бот), далее вы определяете стандартные значения для каждого из действий/значений.
После этого — вы начинаете попарно изменять значения в каждом тесте.
В конкретно вашем случае — тестом будет скорее не прохождение игры от начала до конца, а совершение одного хода игры (если игра пошаговая), с контролем ожидаемого результата на каждом шагу.
По теме — Анализ граничных значений (Boundary Value Analysis) и Эквивалентное разбиение (Equivalence Partitioning).
Использование же случайных значений — так же рассматривается как проблема функционального тестирования, а именно как путь борьбы с «эффектом пестицида». При этом случайные значения беруться только в пределах какого-то из полученных разбиений, а не на всём множестве значений.
В итоге чтобы сделать хорошее автоматизированное тестирование — человеку неплохо бы подтянуть базу по функциональному тестированию.
Человек который захотел поставить у себя камеру (даже в профессиональных целях) — не обязательно айтишник. Он поставил камеру и радуется что она приносит пользу — и это профит.
Сколько времени у такого человека займёт выяснение причин — что произошло с камерой? В худшем случае он подумает что она испортилась и купит ещё одну такую же.
Ваш же сценарий исправления ситуации очень радужный. После сброса камеры ему нужно каким-то волшебным образом понять что это было сделано кем-то из вне и закрыть стандартного пользователя. Хотя вы же писали что при этом стираются все логи, т.е. факт доступа из вне не зафиксирован нигде. Я бы скорее в такой ситуации грешил на сбой оборудования, чем на вмешательство 3й стороны.
Заблокировав такую камеру вы помешали кому-то работать как минимум. Как максимум человеку придётся срочно собираться в дорогу и разбираться что же стало с его камерой. Ведь камера могла выйти из строя в том числе в случае аварии на объекте.
Спас? Вы оставили их владельцев без доступа к камере. Вы не думали что так могли им навредить?
Камеры люди ставят не от хорошей жизни. В труднодоступных местах, тех местах где они редко бывают но за ними нужен присмотр.
гмейл не отличает точек в имени.
т.е. ящики equand, e.quand, и даже e.q.u.a.n.d — все ваши. никто не сможет зарегистрировать ящик отличающийся от вашего только точками.
ссылка на описание в хелпе — support.google.com/mail/answer/10313?hl=en
это workaround для случая когда вам всё-таки нужно пользоваться сервисом, а общаться с саппортом и ждать фикса нет времени.
Или у вас была штатная команда тестировщиков кроме упомянутого конкурса для фрилансеров?
и если вы заранее не позаботились о том чтобы у вас в поле телефон был «валидный» телефон — для решения этой задачи вам нужно будет пытаться обработать эти случаи с разбиением запятой, пробелом, «или». а может человек вообще ввёл «нет» в это поле.
если бы вы использовали gmail можно было бы обойтись разным количеством точек вместо фильтра
my.any.address@gmail.com — основной
myany.address@gmail.com — важная почта
Что-то в этом духе. Все письма бы всё ещё приходили на ваш ящик, но вы бы смогли фильтровать их по полю To.
А если скажем сгруппировать по странам (коду страны, коду города) то уже можно получить симпатичный такой справочник клиентов
Однотипность данных в системе даже если не используются рассылки — важная вещь
Вдруг вы потом решите добавить сортировку по телефону? или захотите проанализировать каких операторов используют ваши клиенты?
Регулярка там или нет — я хочу чтобы в случае опечатки форма мне помогла исправить ошибку до того как уйдёт письмо на несуществующий адрес. Ведь в этом случае мне как минимум придётся заполнять всю форму регистрации заново, и это если я замечу что была опечатка в адресе. А я могу не знать и просто сидеть и ждать когда же мне дойдёт письмо.
«У нас получилось повторить баг на последней версии драйверов и мы всё ещё решаем стоит ли его исправлять»
Бюджет в ней вообще замечательно идёт.
Правда сперва придётся несколько месяцев просто повести учёт чтобы увидеть сколько вы тратите.