Я поставил флаги в  хром "acceptInsecureCerts", "ignore-certificate-errors", "acceptSslCerts",  "--no-sandbox"

Это должно решать пробелму с сертификатами

Апворк?

Ребят, нужен совет: есть 2 проекта с одинаковым базовым функционалом (отличия в дизайне и мелком функционале), тест-кейсами покрыт один проект. Как лучше поступить: 1) создать копию и отредактировать необходимые кейсы, и потом саппортить 2 проекта или 2) унифицировать тест-кейсы таким образом, чтобы они подходили под 2 проекта. В планах 3-ий рескин, и на поддержку в актуальном состоянии тест-кейсов для всех проектов будет уходить слишком много времени. Если у кого-то есть похожая ситуация, поделитесь опытом, пжлста.

а там, где вы это нагуглили, не было случайно совета так не делать? :)
если есть самописные сертификаты, можно их добавить через ssl-root-cas

Мне кажется, что попытка сэкономить время, в перспективе обернётся ещё большими временными затратами на поддержку унифицированного варианта, к которому ты будешь вынужден обращаться с изменениями постоянно.
Чем дальше, тем больше будет различий в 2 проектах, тем больше придётся редачить различные условия приводящие к ожидаемому результату и тд.
Ну это личное мнение конечно.

Логично #1, но на деле работает третий вариант (который будет злить тестировщиков): юзаем один набор тестов на всех проектах. Если в ходе работы тестировщик выясняет, что тест-кейс неадекватен проекту, он помечает тест каким-то особым статусом вроде ToBeUpdated. Позже все такие кейсы отсматриваются и или 1)  подгоняются под проект, или 2) выбрасывают из конкретного проекта.

В итоге каждый проект снабжен уникальным набором тест-кейсов, тестировщики раздражены, менеджерам всë норм.

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

Там отличия проектов насколько большое? Чисто ui, не может быть такого, что фичи разъедутся?

фичи точно одни (все проекты на одной версии админки)

а возможно ли написать общие для всех кейсы по бизнес-логике и отдельные чек-листы по Ui - свой для каждого проекта?

Вручную поддерживать несколько наборов кейсов - действительно сложно, 100% кто-то накосячит. Лучше декомпозировать конечно, и максимально переиспользовать тесты.

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

N проектов - N вариантов. Это как ветки в разработке, в перспективе каждая начинает жить отдельной жизнью с отдельным менеджментом, историей и условностями, которые понятны только нескольким посвященным.

При переиспользовании сущностей в режиме демо всегда всë просто, а на деле неизбежно появляются сущности "с мелкими отличиями". В итоге будет отчаяние и ненависть, бо рядом стоящие
AuthorizeAtLinkedin
AuthorizeAtLinkedin2
AuthorizeAtLinkedinVova
AuthorizeAtLinkedin2-1
AuthorizeAtLinkedinVovaTanya
AuthorizeAtLinkedinNew
уже не помогают, а бесят.

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

От этого всего выгорание и забухание неизбежны.

Но вам может помочь понимание того, что излишняя оптимизация — может быть злом. Не всегда проектов N. Не всегда все надо обновлять. Не всегда все надо тестировать. Ограничения иногда наш друг, товарищ и еда, а иногда единственное спасение.

Идея какого-то единого набора тестов, которые можно прикладывать ко всем новым проектам (у нас платформа, у нас проекты в принципе идентичны, все дела) разумна, но только если все новые проекты на платформе поставляются as is, без тюнинга.

У меня был фэйл в таких условиях: вроде тесты показывают, что багов нет, а на деле багов выше крыши, заказчик злой, программисты злы, бухгалтерия зла, империя зла, а дурак — тестировщик, бо исходные данные были неверны ("Да там разница мелкая, только в юай, не парься!").

Да, все магазины на платформе в принципе похожи, как все люди друг на друга похожи. Но предлагать всем одни и те же ботинки — ой, будет бэмц…

С тестами та же проблема.

Вероятное решение - переиспользовать тесты,  максимально лишенные детализации. Некоторые называют это чек-листами, но суть одна и та же, от тестов остаются только заголовки, и подразумевается, что тестировщик будет в состоянии понимать/знать, что надо делать. В теории, опять же, звучит просто, в реалии это сложно, но уж лучше 20% фэйла на 80% успешности, чем "все, сука, злые" на 100%.

спасибо всем, кто отозвался, примерная модель образовалось. чувстую, прям в больное место попал :)

Бухать & Выгорать! (© на пиратском стяге нашего боевого судна)

test.io, bugfinders(digivante.com)

test.io лол, не знал что епам такой хернёй занимается