Is it correct to have more than one Then in a single Cucumber scenario?

Question

I am new at Cucumber. I am trying to write a feature file that tests

1. a new drop down on an existing page
2. and on selecting this new value entry goes in a new DB Table

I have written this feature file. It doesn't seem correct.

• I'm not sure if we can have two Thens.
• Or is there some way we can have interdependent features, like one feature for the new drop down and one for the database entry?

The feature file is like

Scenario: Admin user should be able to assign ReadOnly role to a searched user via  Change User page

Given user logs into webapp with Admin role 
And Navigates to Change User page 

When user searches for user with id 123 
And clicks select link corresponding to correct id

Then Change User page loads 
And it has a new drop down with Read Only role
And when user selects MS distributor in drop down  # note when with small w
And Presses Submit button then a new entry is saved in DB table # then with small t

Or maybe I can use the following:

Scenario: Admin user should be able to assign ReadOnly role to a searched user via  Change User page

Given user logs into webapp with Admin role 
And Navigates to Change User page 

When user searches for user with id 123 
And clicks select link corresponding to correct id to open Change User page
And it has a new drop down with Read Only role # need to check this new value in my selenium test case
And when user selects MS distributor value in drop down  # note when with small w
And presses Save button 

Then a new entry is saved in DB table

I'm looking forward to learning from your experience.

Answer 1

With what I understand so far, I'd write your scenario something like this:

Scenario: Admin user should be able to assign ReadOnly role to a searched user via Change User page
    When I log in as an admin
    And I navigate to the Change User page
    And I search for the user with ID 123 
    And I click the link to user 123's Change User page
    And I select the MS distributor value from the dropdown with the Read Only role
    And I press the Save button 
    Then a new entry is saved in the database table

The main point is that there is no need to assert that the dropdown exists. Just use it. If the dropdown doesn't exist, the scenario will fail.

When (and Ands following Whens) is for user actions. Then (and Ands following Thens) is for assertions. It's fine to have multiple When/Then sections in a single scenario; there is just no need for that here. I like a blank line before the second and later Whens to make it easier to see that there are multiple such sections.

Other points:

• Every step should have a clear subject, meaning the subject of the sentence: "the user" or "I". I used "I" rather than "the user" for brevity. It would be fine to use "the user" throughout too.

• I'd use When rather than Given for your first two steps because they're worded as though they are part of the series of actions that the user is taking. Alternatively, you could write two steps worded as though what they say were already the case and use them with Given:

  Given that I am logged in as an admin
  And I am on the Change User page
  

• "a new entry is saved in the database table" is vague, and too nuts-and-bolts for scenario language. Reword that to be specific and to say what's happening in business terms.

Answer 2

When you've finished writing your code, and it all works, what will someone (or a something like an automated system) be able to do that they couldn't do before?

Can you think of an example of that?

I'm pretty sure that what will happen is not putting a field in a database. Not unless someone else is using that database, and even then, the capability they have will be reading the information you just put in.

What you told me in the acceptance criteria is this:

Admin user should be able to assign ReadOnly role to a searched user via  Change User page

Can you give me an example of that? Can you give me an example of an Admin user? What will they be able to do? Or not be able to do? What will the user not be able to do? Can you give me an example of an entry they might want to edit?

Whenever I see anything generic ("a user", for example) I'm going to ask you for an example. Give me a name! Even if it's a silly, funny one.

Here's (an example of) the kind of thing I mean:

Given Andy Admin has privileges for changing users
And Reggie Writer is a user with privileges for writing entries
And a page on "Dancing with Unicorns" is editable to writers
When Andy Admin changes Reggie Writer's privileges to be Read Only
Then Reggie Writer should no longer be able to edit the page "Dancing with Unicorns".

You'll see that the language isn't tied to the implementation. You can't tell whether Andy and Reggie are using a web page, an app on a mobile phone, or an old-style DOS prompt. It's about the problem, not the solution. Databases are usually one way to solve a problem.

Also, the database entry has no value unless it actually gets used. A scenario has to have a valuable outcome.

It can certainly have more than one of those:

Given Martin Moneybags has plenty of money <-- we could define how much if we wanted
And he's authenticated himself with the cash machine
When he asks for £1000
Then the cash machine should give him £1000
And it should debit his account by £1000.

You wouldn't want to forget that last one, after all.

It's completely OK to have more than one Given, and more than one Then.

Some people have a rule that there should only be one when. However, if the important behaviour is about the interaction of two people's actions, or the interaction with something like time passing, then it's OK to have more than one When. That's a rare scenario, though.

If you have more than about seven steps, look to see if there are some contexts or outcomes which are pretty common and which you could move into a different feature. For instance, I would expect to see all the scenarios which deal with people drawing money on an overdraft to be in a different feature, even though they might share some of the same steps.

More important than anything else is to talk to the person who understands the problem. Ask them for an example. Have a conversation. If you're doing it for yourself, talk to a rubber duck, at least. It's a stand-in for the conversation you wish you could have with future-you.

If you're not having conversations, you're not doing BDD.