Лучшие практики BDD для разработки сценариев Cucumber для форм

Допустим, у вас есть форма, которая создает нового пользователя. Как написать сценарий с огурцом?

1.)

Given I am logged in as admin
When I create a new user
Then I should see "Successfully created user"

2.)

Given I am logged in as admin
When I go to Create new user
And I fill in "Name" with "Name111"
And I fill in "Password" with "Password111"
And I press "Create new user"
Then I should see "Successfully created user"

Если вы выберете 1.) где вы документируете требования для пользователя (у пользователя должны быть имя и пароль). Я вижу, что BDD - это поведение, но в какой-то момент вы и заинтересованное лицо должны указать, какими свойствами должен обладать пользователь, не так ли?

Я новичок в BDD, поэтому ценю любой совет ...


ruby-on-rails tdd cucumber bdd
person peyote    schedule 13.12.2010    source источник

Ответы (3)


arrow_upward
14
arrow_downward

Вам следует прочитать Императивные и декларативные сценарии .

- Аслак. Создатель огурца.

person Aslak Hellesøy    schedule 15.12.2010

arrow_upward
2
arrow_downward

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

Выясните, что отличает создаваемый вами продукт от всех похожих продуктов, а затем нацельтесь на это как на ценность сценария. Тогда это будет выглядеть так:

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 (разработка, основанная на приемочных тестах). Вот почему мы используем такие языки, как Пример, Сценарий, Учитывая, Когда, Затем, Контекст, Событие, Результат вместо Тест, SetUp, TearDown, Act, Arrange, Assert - поэтому мы можем поговорить об этом с бизнесом, бакалаврами и тестировщиками на одном языке.

См. статью Дэна Норта о преднамеренном открытии и остальные его блог, и удачи вам с BDD!

person Lunivore    schedule 14.12.2010

arrow_upward
1
arrow_downward

Любой из них будет работать. С # 1 вы создадите шаг для обработки заполнения формы. Я предпочитаю гибрид №1 и №2, потому что я часто использую схемы сценария, например:

Background: 
 Given the following users exist:
   | email             | password        |
   | [email protected]  | testpassword23  |
   | [email protected] | notthistime     |
   | [email protected] | welcomeback     |

  @login @authentication
  Scenario Outline: Authentication
     Given I am on the new user session page
     When I login with "<s_email>" and "<s_password>"
     And I press "Login"
     Then I should see "<s_message>"

  Examples:
    | s_email           | s_password       | s_message                      |
    | [email protected]  | testpassword23   | Signed in successfully         |
    | [email protected] | itriedreallyhard | Invalid email or password.     |
    | [email protected] | testpassword23   | Invalid email or password.     |
person Austin Lin    schedule 13.12.2010