приятно использовать при множествах проверках и без цикла
когда у тебя в одном тесте проверяются >1 утверждения

то есть я поясню. два абстрактных варианта:

1 тест и 10 проверок внутри

1. подготовка данных 1 секунда. каждая проверка 1 секунда. если мы запускаем в 1 поток, то получается мы тратим 1 секунду на подготовку и 10 на проверки. итого 11 секунд. если мы запускаем в 10 потоков, то мы тратим в каждом потоке 1 секунда на подготовку и по секунде на тест, итого 2-3 секунды. тратим ресурсы, но получаем в 4-6 раз ускорение тестов

2. подготовка данных 20 секунд. каждая проверка 1 секунда. если запускаем в 1 поток, то получается мы тратим 20 секунд на подготовку и 10 секунд на тысты, итого 30 секунд. если запускаем в 10 потоков то мы тратим в каждом потоке 20 секунд на подготовку и по секунде на тест, итого 21 секунда. тратим ресурсы но выгода всего в 1.5 раза. стоит задуматься а стоит ли, когда в этот момент могли бежать другие тесты

это на ui тесты не похоже. вы про юниты?

я абстрактно

Например

assert 200
assert “success” in text_response

?

если это UI и на каждый тест создается новый инстанс браузера то изначально дробить тесты на максимально мелкие не выгодно

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

Я в таких случаях failfast падения бы делал, т.к оба исхода берутся из
Одного объекта

Если же ты проверяешь N урлов, то это другой разговор

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

еще зависит от ресурсов, если их много то че бы нет

их всегда мало

в общем много факторов все это пробуется и рассчитывается

ну у кого как)

не помню, чтобы где-то куа кричал - хватит, хватит столько ресурсов ))

тогда я первый)

работаешь в компании по продаже облачных решений ), aws? google cloud? )

не, у нас железки

а, ну ок ) считается

MRG)