Как указано здесь в отличном ответе - каждый сценарий, по сути, представляет собой один контрольный пример и поэтому должен быть четко отделен.
Тем не менее, важно понимать, что задано / когда / тогда (в своей самой основной сути) эквивалентны традиционным трем этапам системного теста: Arrange / Act / Assert, следовательно:
Given : привести систему в известное состояние
Когда : Командуйте системой (что вы хотите проверить)
Тогда : Утвердите, что результат был тем, что вы ожидали.
Вот и все!(конечно, BDD гораздо больше, но это основы исполняемой спецификации)
Given User is on Home Page не приводит систему в известное состояние, но Given I am registered - это .Хотя этого может быть недостаточно, чтобы заявить об этом, потому что, как только вы поймете, что и почему в сценарии, вы быстро поймете, что вам не хватает чего-то более конкретного в качестве примера.
Перефразируяпредыдущий ответ:
Given I am registered -> настроить пользователя (но имеет ли значение, кто?) как зарегистрированного в системе (запись в базе данных?), зарегистрированного для чего?имеет ли значение для результата?
When I sign in -> Дать системе команду на вход (кто?) - это может быть сделано через веб-форму или через API (или по телефону?).Имеет ли значение, в какое время вы входите в систему, можете ли вы войти сразу?
Then I should be signed in -> Проверить ответ из веб-приложения, базы данных, сеанса?cookie?
Сказав это, вход в сценарии, вероятно, не стоит использовать BDD для решения, так как они так же хорошо определены, как CRUD - анализ практически не требуется.