Быть того не может

Завтра скину скрин как на локали и как ранит тим сити

Уже комп потушил!

Можно параметрами

весьма спорное утверждение, позвольте как-то его прокомментировать

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

Дизайн либо вслух проговаривается, либо нет, но от этого его не перестает быть.

Не очень понятно, почему через полгода дизайн системы должен появиться вдруг -- он же и был изначально. Что случается за полгода жизни проекта? Все ли проекты одинаковые? Все ли команды делают +- с одинаковой скоростью тесты?

АрХиТЕКТуРа в АвТоТесТах - имхо больше желание надуть щеки и с важным видом затереть о простых концептах написания кода, и зачастую эти концепты напрямую даже не связаны с лейаутом проекта

Дата провайдеры
Группировка тестов по зонам ответственности
Наследование пейдж объектов / API обтектв
Fluent API. и билдеры
Ассерты, матчеры
интеграции с репортингом  и сторонними спервисами (точки входа/выхода)
варианты запуска тест сьютов, фильтрация и логгирование

все это точечные штуки, которые зачастую идут в комплекте с тулингом, и на Архитектуру тестов ®  слабо влияющие.


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

Интересно, как вы тестируете сложный и зависимый от массы пред-условий функционал с подобным "тривиальным" подходом?

Предположим вам нужно протестировать сущность, чтобы создать которую нужно завести еще с десяток других, помельче. И все они опираются на какие-то внешние данные. Не имеет значения откуда вы их возьмете, из бд, из ui, или вообще сгенерируете руками. Не суть.
Часть этих данных из вспомогательных сущностей нужна для создания новой, которая большая.
Как вы будете это делать, или как делаете если уже работаете над подобной задачей?

@panemquotidianum ?

А, да. И что если у вас кейсов с этой большой сущностью сильно не один.

можно написать свой синхрофазотрон такой же как у разработчиков только проще без кешей перфа и багов

Так как задача описана гипотетически, без конкретного примера, опишу его сам, чтобы проще было применю достаточно широкую, но не совсем тупую технологию - AWS:

Представим, я AWS Cloud тестировщик, и я проверяю Имплементацию NAT Gateway. Например, его создание

Вот несколько предикатов, описывающих контекст работы с NAT Gateway (я подглядел в документации, можете и вы посмотреть https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-creating):

required:
NAT Gateway невозможно сделать без NAT.
NAT Gateway входит в Subnet
Nat Gateway ассоциируется с одним и только одним Elastic IP.
optional:
Nat Gateway имеет лимит на кол-во в определенной Availiability zone.


из описанного видно, что тестируя nat gateway на создание, так или иначе будет one-to-many / one-to-one связей с другими сущностями.

реализация теста:
контекст (в данном представляется паттерном data provider):
получение токена пользователя у которого есть VPC, nat. реализуется посредством bd запроса, например. Может быть ORM обертка fluent стиля
db().Get_user().with("vpc").having("nat").get_token()

далее из него можно проверить функционал следующим образом:
UI - иньекция токена в сессию (здесь мы упускаем необходимую 2FA у AWS для простоты случая)
API - подпись запросов в коде формированием Bearer token

положительные сценарии:
с указанием валидных required параметров

негативные сценарии:
с указанием невалидных requried параметров (несответствие типа \ маски)
с указанием недостаточного кол-ва requried параметров

Т.е. формально тестирование через код будет осуществляться путем нахождения юзера с нужными для теста критериями (контекст) и выполнение атомарной операции добавления NAT.

Если представить, что так называемое в условии задачи"много разных компонентов, от которых зависит создание большого компонента" для NAT есть много других компонентов для создания, то, в зависимости от линейности этих связей в части датапровайдера (в моем случае ORM запроса к бд) с развитием продукта просто количество токенов бы увеличилось с одного до N, если важно протестировать, что например NAT нельзя создавать, если баланса на счете нет.

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

суть моего вопроса заключалась в раскрытии того момента, что в сложных случаях не обойтись 2,5 классами и пришлось бы писать энное количество оберток, связей, обработчиков данных и т.д и т.п.
а если еще и присутствует/подразумевается некое множество вариантов использования вы будете неизбежно (чтобы не плодить дубликаты и ради большей гибкости) выносить повторяющийся код во внешние объекты как описано выше, что лишь подтверждает тезис с которого началась беседа: автоматизация сколько-нибудь сложного продукта требует построения некоторой архитектуры (дизайна если угодно), и ее сложность будет расти вместе со сложностью и размерами тестируемого объекта. и от ее качества/продуманности будет зависеть скорость и удобство внесения изменений.
нет, можно и в один класс все запихнуть при желании, но с каждым новым изменением манипуляции с кодом будут требовать все больше и больше времени и усилий, пока не будет достигнут некий окончательный предел, что сделает подобное тестирование абсолютно бессмысленным.

наймите архитектора пока не поздно

Привет.
Подскажите, плз, как лучше в селениде сделать проверку более атомарной по влиянию на неё со стороны состояния DOM.
Элементы постоянно мутируют. И всякие цепочки типа $(...).filter(...).exclude(...).should(Condition.or("", ..., ...)); долго выполняются и могут приводить к ошибкам т.к. в момент проверки состояние элемента уже может поменяться несмотря на фильтры до неё.
Помимо js  есть какие-то хорошие варианты?

@Starforge го в чат "Selenide на русском"

да, спс, зашёл.

Как показывает практика - поздно и они не всегда спасают

Тут все верно, но, как сказал выше @iTerkin, можно существенно сократить рост сложности на верхних уровнях пирамиды тестирования за счет нижних, где все проще и дешевле. Там, правда, начинается другая проблема - управление огромной тестовой моделью.

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

chromedriver 80, c#

Гуглил по этому поводу, нашел только то, что разработчики хромдрайвера уже пофиксили :(

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