The idiosyncrasies of BDD

It’s been a while since I blogged about writing Acceptance Criteria using Behaviour Driven Development, specifically Gherkin (read my previous blogs: A practical blog on how to write Scenarios using BDD¹ and Requirement Pitfalls with BDD²). However, after using BDD to document our Acceptance Criteria with a new client, I thought it was time I revisited the subject to see if I’d learned anything new.

The short answer is, “Yes!” This blog discusses some BDD idiosyncrasies I’ve discovered over the past year and a bit – to my surprise, not all of them are a good practice!

Acceptance criteria using BDD

Before getting started, I’d like to clarify my approach to writing Acceptance Criteria. You’ll notice in the examples provided below that I’m quite specific about the fields and messaging displayed. This is referred to as an ‘imperative’ approach.

I often prefer this approach because my team and I are quite detail oriented. Others may disagree with this approach or even see this as a pitfall of writing requirements, not just BDD. And, over the last year, I’ve also found myself using a more ‘declarative’ approach when writing Acceptance Criteria.

For example, when writing about submitting a form or request, I won’t refer to the specific button used but the action of submitting the request. You’ll also notice I’ve updated some of my example scenarios to reflect this shift.

(Imperative or declarative – want to make up your own mind? I recommend you take a look at: Handling UI in User Stories³.

Using backgrounds to provide context for all scenarios

The backgrounds concept within Gherkin allows you to add a context that covers all your scenarios [4]. Take, for example, the Facebook scenarios used in my previous blog². The common context is that Fred is signing up for Facebook:

Scenario: Providing all required fields creates Facebook account
Given Fred is signing up for Facebook,
When he enters the following required details:

• First Name
• Last Name
• Email
• Re-enter email
• Password
• Birthday
• Gender

And the password provided has 6 or more characters,
And he submits his request,
Then a Facebook account is created,
And an account name is set as Fred’s email address,
And a confirmation email is sent to Fred.

Scenario: Providing an invalid password prevents Facebook account creation
Given Fred is signing up for Facebook,
When he provides a password that does not meet the password requirements,
And submits his changes,
Then a Facebook account is not created,
And the invalid Password validation message for the Password field is displayed.

A background comes in very handy (and also avoids repetition) when you can declare: “Fred is signing up for Facebook” only once. This means I would change the two scenarios above to:

Background:
Given Fred is signing up for Facebook

Scenario: Providing all required fields creates Facebook account
Given Fred enters the following required details:

• First Name
• Last Name
• Email
• Re-enter email
• Password
• Birthday
• Gender

When the password provided has 6 or more characters,
And he submits his request,
Then a Facebook account is created,
And an account name is set as Fred’s email address,
And a confirmation email is sent to Fred.

Scenario: Providing an invalid password prevents Facebook account creation
Given Fred provides a password that does not meet the password requirements,
When he submits his changes,
Then a Facebook account is not created,
And the invalid Password validation message for the Password field is displayed.

As you can see, this is very helpful when you have a lot of scenarios and it’s best to avoid repeating yourself multiple times. It also means your Acceptance Criteria are more readable, which I’m sure your development team will appreciate.

Using a single ‘when’ statement to specify a single event in BDD

Until very recently I was under the impression that it didn’t matter if you wrote multiple When statements in each of your scenarios. Using one of the above examples you can see these multiple When statements, implied by the use of And after When:

Scenario: Providing all required fields creates Facebook account
Given Fred enters the following required details:

• First Name
• Last Name
• Email
• Re-enter email
• Password
• Birthday
• Gender

When the password provided has 6 or more characters,
And he submits his request,
Then a Facebook account is created,
And an account name is set as Fred’s email address,
And a confirmation email is sent to Fred.

This may seem fine, however, following a bit of debate with my colleagues, we referred back to the trusty Dan North article What’s in a Story? and discovered the following:

“The event itself should be very simple, typically only a single call into the production code. As discussed above, some scenarios are more complicated than this, but mostly the scenarios for a story will revolve around a single event. They will differ only in the context (the givens) and the corresponding expected outcomes.” [2]

A When statement that is an event should be a single trigger that prompts your expected outcome (your Then statement). Although North appears open to allowing multiple triggers, he does indicate that ensuring each scenario has a single When statement when writing Acceptance Criteria with BDD is good practice. With this in mind, I’d change my example to:

Scenario: Providing all required fields creates Facebook account
Given Fred enters the following required details:

• First Name
• Last Name
• Email
• Re-enter email
• Password
• Birthday
• Gender

And the password provided has 6 or more characters,
When he submits his request,
Then a Facebook account is created,
And an account name is set as Fred’s email address,
And a confirmation email is sent to Fred.

Although it seems like only a minor change, this is actually better practice. It clearly tells the development team what’s going to be the trigger for respective outcome/s.

Using a ‘but’ statement to explain something shouldn’t happen in BDD

Another lesser-known technique I’ve picked up over the last year is using what’s known as a But statement to explain something that shouldn’t happen.

You can use a But statement instead of an And statement. Technically, Gherkin doesn’t distinguish between the two – however, as a human reading the Acceptance Criteria, the But statement is likely to stand out more if you want to make sure something shouldn’t happen.6

Now, this initially sounded great to me! I thought it would let me clarify when something shouldn’t happen far more clearly. However, a long Elabor8 team debate on using But statements resulted in mixed opinions with a number of camps emerging:

• One camp held Acceptance Criteria (traditionally written by the Business Analyst) shouldn’t be confused with Acceptance Test (traditionally written by the Tester). In other words, Acceptance Criteria shouldn’t go into detail about what shouldn’t happen but point out what’s expected.7 This confusion was potentially caused by the fact we have language like Gherkin (originally developed by Developers and Testers) now being used by Business Analysts.
• The Use Case camp debated whether this was an Exception or Alternative Use Case. We agreed that using But made it more than likely an Exception case, as this would prevent the user from achieving what they set out to do.8
• Finally, one camp believed using But was OK if used in moderation and only where it makes sense.

As the Business Analyst within your Development team (or among other Business Analysts), you should decide which direction you want to go and ensure you adhere to it. My current team will probably need to discuss the use of But again after this debate. However, currently we’re OK with using it.

So, with all of this in mind, I’ve changed the order of the above example once again:

Scenario: Providing an invalid password prevents Facebook account creation
Given Fred provides a password that does not meet the password requirements,
When he submits his changes,
Then the invalid Password validation message for the Password field is displayed,
But a Facebook account is not created.

Slightly changing the scenario order and adding But now makes it very clear a Facebook account should not be created when an invalid password is provided.

The great thing about writing Acceptance Criteria with BDD is that it uses plain English to explain expected behaviour. Of course, there are always ways you can improve how you write your own Acceptance Criteria. The different practices and techniques demonstrated above are just a few examples. Some are considered good practice; for others you’ll need to use your judgement.

I’m sure there’s still plenty of ways I can improve, so I’ll report back as I go. I hope you’ve learned a few new things about writing with BDD and will continue to join me on my journey of discovery!

Suggested reading:

• Given then when
• What’s in a Story?: Dan North
• Writing Use Cases: Exception or Alternate Flow?: Bernd Lohmeyer

References:

1.  A practical blog on how to write Scenarios using BDD
2.  Requirement Pitfalls with BDD
3. Handling UI in user stories