Сценарии, которые вы написали, довольно низкого уровня.Если вы на самом деле не производите функцию безопасного входа в систему для продажи, я бы остался доволен удачным кейсом и модульным / ручным тестированием.Если вы этого не сделаете, вы создадите так много сценариев, что это будет кошмар обслуживания.
Узнайте, чем отличается продукт, который вы создаете, от всех аналогичных продуктов, а затем определите его как ценностьсценарий.Тогда это будет выглядеть так:
Given Fred is logged in
When Fred <does something>
Then Fred should <get some really differentiating value>
And <something else happens>
Придерживайтесь действительно высокоуровневых возможностей, а не низкоуровневых шагов на основе форм.Например:
Given there is already a question on BDD and Cucumber
Given Peyote is logged in
When Peyote proposes a question on BDD and Cucumber
Then Peyote should see other questions on BDD and Cucumber.
Существует концепция, называемая «Парадигма страницы», в которой вы создаете класс со всеми низкоуровневыми шагами, которые может выполнять страница или экран.Затем вы можете вызывать эти низкоуровневые шаги на странице из высокоуровневых осветительных приборов Cucumber.
Ваш бизнес будет гораздо больше вовлечен в подобные сценарии.Основная цель BDD - не создавать автоматизированные тесты, а вести беседы вокруг сценариев, чтобы вы могли выяснить, в чем проблема, и какие другие варианты вы могли бы рассмотреть, прежде чем приступить к реализации кода.Автоматизированные тесты являются хорошим побочным продуктом.
Общение и обучение, которое вы получаете, общаясь с ними, - это то, что отличает BDD от ATDD (Acceptance Test Driven Development).Вот почему мы используем такой язык, как Пример, Сценарий, Дано, Когда, Затем, Контекст, Событие, Результат вместо Test, SetUp, TearDown, Act, Arrange, Assert - так что мы можемпоговорите об этом с бизнесом, бакалаврами и тестировщиками на одном языке.
См. статью Дэна Норта о намеренном открытии и остальную часть его блога для получения дополнительной информации и удачи с BDD!1021 *