What is BDD? What is Behavior Driven Development?

What is Behaviour Driven Development?

Aka BDD

I'm glad you asked.

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