What is Behaviour Driven Development?
Aka BDD
I'm glad you asked.
Welcome to Development That Pays
Let's jump straight in with an example of a Behavioural Test for a Cash Machine:
Given the account balance is £100 And the card is valid
And the machine contains enough money When the Account Holder requests £20
Then the Cashpoint should dispense £20 And the account balance should be £80
And the card should be returned
The first thing to notice is that the test is written in - more or less - plain English.
The second thing to notice is that the test made up of three distinct sections.
In the BDD world they're referred to as
Context, Event
Outcomes
Context is the "starting state" Event is the thing that the user does
and Outcomes are the expected results of what the user does.
If you were with me two episodes ago, I did a test that could be called "Starting my motorbike."
I could describe that test in Context / Event / Outcomes format as follows:
Given the battery is charged And there is sufficient petrol in the tank
And the petrol tap is in the on position And neutral gear is engaged
And the throttle is open 1/4 When I operate the kick starter
Then the engine should start
Perhaps their greatest strength of Behavioural Tests
is that they describe in a very direct way the set of the behaviours that the customer
can expect from the system.
The list behaviours taken together form a "contract" of the complete set of behaviours
that the system is expected to exhibit.
If all Behavioural Tests pass then the contract has been upheld; if any of the tests fail,
the contract has been broken.
Behavioural Tests can be written for a system at any time: before, during or after development.
It can be very difficult to write unit tests for an existing system
but writing behavioural tests for an existing presents no special difficulty.
The case where the tests are written first is termed Behaviour Driven Development.
The plain english nature of the Context / Event / Outcomes format means that the business
people can focus on describing the behaviours that matter to the customer.
When the Development Team begin their work, every one of the tests will be running and
- in the absence of any code - failing.
As more code is written the tests will begin to turn from red to green.
When they're all green, the job is done.
There's another benefit here that may not be immediately obvious.
As a developer myself, I can confirm a tendency to write too much code
Or code that does too much
Or code that includes some degree of supposed "future proofing".
BDD helps to rein me in.
To keep me focused on getting the behavioural test to pass.
Nothing less.... And, importantly, nothing more.
If all of this sounds too good to be true, I should point out a couple of drawbacks:
- Behavioural Tests tend to be slower to run than unit tests - often by one or more orders
of magnitude. - Behavioural Tests, when they fail, indicate
that something went wrong... but may give little or no indication of the root cause.
If you saw the last episode, you'll recall that identifying the root cause is a key strength
of Unit Testing
Which is my clumsy way of trailing the next episode, where I'll be comparing and contrasting
Unit Testing and Behavioural Testing
And, of course,
Test Driven Development (TDD) and Behaviour Driven Development (BDD)
I hope you'll join me.