Запускайте второй сценарий только в том случае, если первый проходит проверку JBehave.

Ваши сценарии должны быть независимы друг от друга и быть полным представлением одной цели в одной ситуации. Объединение сценариев вместе в BDD является антишаблоном, и его следует избегать.

Следующий вопрос: почему вы применяете стратегию отказоустойчивости для функционального тестирования? Это необходимо пересмотреть, чтобы определить, является ли это обоснованным подходом для вашей ситуации. Хотя отказоустойчивость является нормой для конвейера развертывания, это не лучший подход для автоматизированного функционального тестирования в целом и, в частности, во время разработки, ориентированной на функции, с помощью BDD. Как правило, лучше использовать отказоустойчивую стратегию автоматизированного функционального тестирования. Я советую вам выполнить все тесты до конца. Обычно это обеспечивает большую ценность. Это позволит избежать раннего неудачного теста от маскировки потенциально более серьезных неудачных тестов или тестов против более важных или ценных функций. Подробный отчет об испытаниях позволяет расставить приоритеты по устранению неполадок.

Если триггер сбоя для всех трех сценариев является общим, используйте общий предусловный шаг. например Given the customer is authorised. Затем просто защитите каждый сценарий этим предварительным условием.

Если триггером сбоя является окружающая среда, используйте тест погоды в бегуне или используйте соответствующий тестовый хук @Before. например Наличие LDAP или базы данных. Затем проверьте это предположение, используя каждую функцию или сценарий.

Если ни один из них не подходит, вам нужно будет уточнить ваше требование с некоторыми примерами сценариев, которые вы используете.

Возможно, вы могли бы использовать скомпрометированные исключения, но JBehave (и сценарии BDD в целом) на самом деле не предназначены для такого использования — каждый сценарий должен быть независимым.