У меня другой вопрос возник. А сталкивался ли кто-нибудь из вас с ситуацией, когда результат выполнения шага не должен влиять на результат выполнения следующего шага? Как вы поступаете в этом случае и какой, считаете должен быть статус теста passed (в отчете все равно шаг будет отмечен как failed) или failed?
Я в такой ситуации действую через try catch finally и последним шагом делаю ассерт на флаг, привязанный к потенциально зафейленному шагу, но который не должен помешать довести тест до конца.
В результат в отчете у меня опциональный шаг помечен как failed, тест помечен как failed и собственно последний шаг по проверке флага помечен как failed.

это при условии что время на сетап такого теста статично и не превышает выполнения одной-двух итераций. тогда их можно параллелить

Я, наверно, не совсем понял ваш комментарий.

Возьмем для примера мой тест.

У нас есть 2 системы, от которых приходят ответы в наш сервис.

Система 1 выдает ответ, но получение ошибки в этом ответе не влияет на получение ответа от Системы 2.

Это часть бизнес-процесса.

тогда почему это шаги одного теста?

Это означает N проверок в тесте в разное время. Для этих нужд изобрели delayed assert

Так в тесте в том числе и проверяется, что если свалились на ответе от системы 1, с ответом от системы 2 ничего не случилось.

Но я понял вашу мысль. Нужен тест, обрубаемый на шаге получения ответа от системы 1 и тест, в котором пропускается шаг получения ответа от системы 1. Ну и большой тест, где все вместе.

это опять же при условии что подготовка данных для таких тестов не превышает выполнения каждого

soft assert еще называют

Ну да, это нужно оценить. Я подумаю.