Смотри. Я хочу объяснить что не нужно использовать class Exception, а нужно использовать классы которые относятся к конкретным ошибкам и обрабатывать их.

то есть кто то делает в коде
raise Exception("херня хэппенд") а ты хочешь чтобы был raise HernyaHappend()

Если шаги не зависят от других, то по идее их надо вынести в отдельные тесты.

Да.
Не exept Exception', a expet KeyError`, как пример.

У нас в фреймворке уже есть определенные классы для ошибок.

Они в рамках одной тест спецификации.

Ну если кому то не очевидно, значит пора сделать coding style в вашем проекте..

не очевидно Junior'y )

но если где то будет

except Exception as error:
    if error.msg = "херня"

то за это бить палками по рукам

И что это должно значить? Если твой шаг в тестах может падать как угодно, но это не влияет на остальные шаги, вынеси этот шаг в отдельный тест - пускай себе падает как угодно и не надо его оборачивать в try...except - увидишь ошибку в отчёте, и при этом остальные тесты будут тоже запущены.

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

И вроде как если что-то должно упасть, то на это пишут проверку. Например в pytest

with pytest.raises(SomeException):
    run_my_code()

В unittest вроде как есть аналог, только без with.

@cykooz, как пример

1) Включить обрудование
2) Выставить на нёи пармерты (примерно 20 метрик)
3) Открыть вкладку
4) Проверить каждую метрику и записать в отчет.


получаеться, у нас есть
Setup: тут включаеться оборудование которое и генерирует метрики. Если Setup не прошёл то завершение работы всего тестового сценария.
Step 1: проверить метрику 1. Проверка метрики выдаёт raise. Это не моя прихоть, так устроен фрэймворк. И я должен обработать эту ошибку.

и вот мы уже имеем 20 шагов.

Так же возможно дополнительные действия, например открыть вкладку, на не нажать кнопку уоторая откроет табличку и там 10 метрики. А при нажатие другой кнопки, другая таблица и там другие метрики.

При желании на эту тему можно книгу написать. А может уже кто-нибудь написал

Если есть фиксированный список ошибок, которые можно написать в except, то напиши их. Если же тестовый сценарий предполагает, что там вообще может любая херня случится и это не должно повлиять на остальные шаги - пиши except Exception: и не парься

Да я то пишу конкретные ошибки. А вот коллега пишет Exception и я хотел доходчево ему объяснить, что это не правильно.

Всё зависит от того что именно проверяет тест. Если тест должен проверить список ошибок, которые может выкинуть какой-то шаг, то указывай этот список. Если для теста пофиг - то не указывай.

Неправильно учишь.
Надо except Exception:  #noqa 😂😂😂

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

Я просто хочу что бы человек не бездумно писал

try:
    some()
except Exception as error:
    bla_bla(error)

а писал, так как мне кажеться правильней:

try:
    some()
except (KeyError, FrameWorkError) as error:
    bla_bla(error)

try:
    some()
except Exception as error:
    bla_bla(error)

try:
    some()
except (KeyError, FrameWorkError) as error:
    bla_bla(error)

Думаю в твоём случае (когда ты не можешь в тестах контролировать какие ошибки происходят в коде), нет ничего страшного в Exception. Особенно если в тест-кейсе написано:
- <сделать 1>
- независимо от результата <сделать 2>