Такие мысли на этот счет:
1. Если проверок в тесте много, возможно, это нарушение Single responsibility (
https://en.wikipedia.org/wiki/Single-responsibility_principle)
2. Если же эти проверки делаются в одном тест кейсе, потому что хочется сэкономить на обращениях к странице и вы уверены (но я бы не стал), что каждая проверка не затрагивает любую другую (то есть осознано принимается риск "грязного" контекста), то как минимум каждая проверка лучше бы имела свой ассерт, т.к. тесты собой представляют еще и подобие документации, и асерт на проверку выглядит сильно нагляднее, чем обьект, который будет содержать разные по смыслу проверки.
2.1 более того, если этот финальный обьект для ассерта содержит разные по своей зоне ответственности проверки (например, в профайле на линкедин залить новый аватар, затем сразу поменять имя, поменять год рождения, отключить интеграцию с 3rd party сервисами, сменить пароль), то проверка его в конце будет означать то, что тест должен дожидаться конца всех проверок. Возможно, fail fast (падение при первой же сломанной проверке) куда более предпочтительный вариант.
2.2 Тем не менее обьект с результатом нескольких проверок существует в природе, но скорее нужен для накапливания однотипных проверок, как-то: перебрать все url в цикле, собрать коды ответа и сверить, что нигде код не отличается от 200. В таком случае проверку можно отложить (не фейлить тест сразу при первом падении), чтобы при большом кол-ве урлов например получить исчерпывающую инфу по тому сколько и какие урлы вернули результат, который ты не ожидал. Гуглить delayed/soft assert
вот если примерно этим руководствоваться, то основные понимания как организовать тест кейс появятся. чем атормарней тест (тестирует что-то одно), тем обычно лучше, но иногда нет ресурсов\времени делать такие атомарные тесты
