Best BDD practices for designing Cucumber scenarios for forms

Question

Lets say you have a form which creates a new user. How do you write your Cucumber scenario?

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"

If you choose 1.) where do you document the requirements for a User (A user should have a name and a password). I see that BDD is about behavior but at some point you and the stakeholder have to specify which properties a user should have, don't you?

I'm very new to BDD so I appreciate any advise...

Answer 1

You should read Imperative vs Declarative Scenarios.

--Aslak. Creator of Cucumber.

Answer 2

The scenarios you've written are fairly low level. Unless you're actually producing secure login functionality to sell, I'd stick to the happy case and unit / manual test the rest. If you don't, you'll create so many scenarios it'll be a maintenance nightmare.

Find out what differentiates the product you're creating from all the similar products, then target that as the value of the scenario. Then it will look like this:

Given Fred is logged in
When Fred <does something>
Then Fred should <get some really differentiating value>
And <something else happens>

Stick to the really high-level capabilities, rather than low-level form-based steps. For instance:

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.

There's a concept called the "Page Paradigm", in which you create a class with all the low-level steps that the page or screen can perform. You can then call those low-level steps on the page from within the higher-level Cucumber step fixtures.

Your business will be much more engaged with scenarios like this. The main purpose of BDD is not to produce automated tests, but to have conversations around the scenarios so that you can find out where you're going wrong and what other options you could consider before you go to the trouble of implementing the code. Automated tests are a nice by-product.

The conversations, and the learning you get by talking through them, are the things which make BDD different from ATDD (Acceptance Test Driven Development). That's why we use language like Example, Scenario, Given, When, Then, Context, Event, Outcome instead of Test, SetUp, TearDown, Act, Arrange, Assert - so we can talk about these with business, BAs and testers in the same language.

See Dan North's article on Deliberate Discovery and the rest of his blog for more, and good luck with the BDD!

Answer 3

Either one will work. With #1 you would create a step to handel the filling in of the form. I prefer a hybrid of #1 and #2 because I use Scenario Outlines alot for example:

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.     |