Rewarding Good Behaviour

As developers these days we are very driven people, there are numerous xDD philosophies that we can chose to become followers of.

One such philosophy is Test Driven Development (TDD).

In essence TDD involves writing the tests before writing the code, this focus on what functionality a piece of code should offer and how you should interface with it before you actually produce the code brings many advantages.

But TDD tends to be a tool of a developer, he or she applies it when writing unit tests concentrating specifically on a single class.

What if we could apply the same thinking to an entire system? And what if we could bring these benefits to everybody and not suggest those of us that are conceded "techy"?

This leads us to the idea of Behaviour Driven Development (BDD).

Given, When, Then

Much like TDD, BDD attempts to define the specification of a system before it is written, the key difference being that this specification is by example and is phrased in a ubiquitous language that everyone who has a stake in the outcome of the system agrees upon and understands.

These examples of the desired outcomes for the system are not technical because there not concerned with implementation, remember the system hasn't been implemented yet, the ubiquitous language should be understood by developer, tester, business analyst, product owner and even the end-user of the system alike.

Everybody can agree that you need to be able to login into our system and everyone can agree that Given that I enter the correct username and password, When I select login, Then I should be logged in.

Because we are simply providing examples of the expected behaviour of the system irrespective of implementation we create a living document that grows as the system grows and can be used by anyone to understand what the system is and what it does.

When the system regresses and no longer conforms to this specification it is clear for all to see.

The Three Amigos

The move away from technical detail in defining the behaviour of a system lies at the heart of BDD, the definition of the specification should have input from all sides.

Developer

Tester

Domain Expert

Between these three amigos all aspects of a potential system can be covered, what is technically possible, what quality looks like and what makes sense within the domain that the system will operate. 

Producing a specification is as much about clear communication between these members of the team as it is about specifying the tests a system must pass in order to be fit for purpose.

The Story We Want To Hear

BDD has a clear alignment with Agile development, the concentration on telling the story of the user and the system means the testing output of BDD should inspire great confidence that what was required had been delivered.

Specification by example also allows only the minimum set of requirements to be defined that represent value and produce a viable product.

The living document allows rapid iteration of the story we want the system to fulfil as well as clearly defining the work required to get their.

The ability to have a ubiquitous language and narrative from the project starting to the first iteration rolling of the production line is a very powerful tool.

The What Not The How

The cause of many projects getting caught in quicksand is getting overly bogged down with the "how" and not the "what" in the initial inception.

BDD as with Agile should help focus the mind that providing we will be able to supply an answer to "how" the much more important questions are "what" and even "why", failure to be able to supply answers to those two questions means your doomed to fail.

Difficulty in writing the features of a system should be a clear sign that you don't have a clear vision for what you are trying to achieve, don't just start building something work out the right thing and build that. 

The most important feature you every right should be Given We produce a system that does this, When Users get there hands on it, Then They will wonder how they ever lived without it.