I’ve been asked about TDD and BDD by a few people over the last couple of weeks, so I thought I’d post a couple of summaries and some useful links. Last week I posted about TDD, so this week it’s BDD’s turn.
Whilst TDD is a technical approach written by developers, Behaviour-Driven Development (BDD) is much more friendly. As its creator, Dan North, describes BDD as “a way to describe the requirement such that everyone – the business folks, the analyst, the developer and the tester – have a common understanding of the scope of the work.” It’s a very collaborative approach, with the whole team (including the product lead) discussing requirements and agreeing solutions based on what customers need. It is described as an outside-in methodology because the starting point is to establish what you want to happen, then you agree how to achieve it. As North says, “software delivery is about writing software to achieve business outcomes.”
Although not a compulsory format, these requirements usually comprise two parts:
- The title and narrative: this is similar to a user story and includes a summary of the business benefit;
- Acceptance criteria: a set of scenarios which, once fulfilled, provides evidence that the requirement has been completed.
The most popular way to write acceptance criteria is using a style called Given, When, Then. It has three parts which are:
- Given: this describes the state, context or pre-conditions
- When: describes the action being taken or event that happens
- Then: describes the desired outcome or behaviour
- You can also put And in there if there are multiple points to be aware of.
Stories should be small enough to fit in an iteration.
So, an example could be:
Title: Adding comments to blog posts
Narrative:
- As a reader of the blog
- I want to be able to leave comments
- So that I can join in the conversation about the topic
Acceptance Criteria:
Scenario 1: Adding comment to blog post
Given I am reading an individual blog post
And I am logged in
When I leave a comment
Then it should be immediately visible against the blog post
Scenario 2: Notifying the author that a commented has been added
Given I am the author of a blog post
When someone leaves a comment on one of my posts
Then I should receive notification that someone has commented
And I should receive a copy of their comments
Scenario 3 …
Dan North’s excellent blog post What’s In A Story walks you through an example for the workings of an ATM.
However, the format is not the crucial element here. Liz Keogh, another BDD luminary, encapsulates the sentiment when she says “having conversations is more important than capturing conversations is more important than automating conversations.”
In summary
Although TDD and BDD differ in their viewpoints (the former being technical, the latter being from a business standpoint), both are approaches that focus on the end result. You set tests upfront, then work towards satisfying them. Both force you to consider what outcomes you want to be displayed before you start development. This might sound obvious, but it often doesn’t happen in the depth that is necessary.
Note: I’m not an expert in TDD or BDD, but I have worked with people who know what they’re talking about so I’ve asked them to help. Thanks to Kikyoung Kwon, Paul Bassan and Dan Ashby.
Image (homepage): Peter Togle