[VIDEO] Behaviour Driven Development

Previously...

I dared to question the work of a master of his field: I went up against Dan North.

The originator, the father - the godfather - of Behaviour Driven Development.

And not in a small way: I questioned the canonical example of BDD: the infamous ATM Example.

Today...

I'll eat a big fat spoonful of humble pie.

Once upon a time

I don’t know how much you know about my move into IT?

I used to have a proper job. In industrial marketing.

And I left it to join a “dotCom”.

My “transferrable skill” was project management. But my dotCom Project Management career lasted less than a fortnight.

(That’s a thrilling tale for another time.)

I lasted longer - years longer - in my next role: as a Business Analyst.

A role where I wrote Functional Specifications.

A Functional Spec fits into the space between (a) the Business Requirements Document, and (b) the Systems Requirements Document.

The three together answer the questions: Why?, What? and How?

I understood that at a intellectual level. But in practice I found it all too easy to stray from the WHAT into the HOW.

I hadn't realised how often I was doing so, until I worked with one particular chap.

He had his very own catch phrase.

I'd say something like: “The user selects an option from a dropdown… “

And he’d say: “Implementation detail!”

I’d try again: “The user clicks….“

And he’d say: “Implementation detail!”

Damn! It was hard to get to the end of a sentence with the guy around!

He was right, of course: there are many ways to skin a cat, and it wasn't our job to specify any of them.

Trouble is, I quite like the implementation details. I’m interested in user interface design. I’m interested in usability.

Steve Krug’s book “Don’t Make Me Think” is still one of my favourites.

It’s an interest that got me into trouble in my Functional Spec-writing days. And it’s still getting me into trouble today.

Ten months ago

Fast forward to the present day. And then rewind ten months.

I borrowed a “classic” example from the godfather of BDD - Dan North - for one of my episodes.

And for months, no one batted an eyelid.

And then they started to drip in: comments to say that the the sequence of events… wasn’t quite right.

Among them, an email. An email to say that the example... was an example of bad usability!

That got my Steve-Krug-Don’t-Make-Me Think Spidey-sense tingling.

A usability challenge! I love a usability challenges!

You ask for money,
the card pops out
You grab the card and walk away... leaving the money behind.

Crazy! Terrible usability!

I suited up and swung into action.

You know what happened next. Last week’s episode happened.

You know, the one where I said this was broken. And went on to suggest some "improvements".

I even got you in on the act, helping to refine my improvements.

Enter Mike Jones

Mike Jones left a comment.

Mike's comments are always good. Always.

I wondered why he'd left such a long comment.

As I scanned it,... one the word jumped out at me from several places:

ORDER

In that INSTANT, I knew I was in trouble.

Without reading on, I went straight back to Dan North's classic example

Here it is, verbatim:

    Given the account is in credit
    And the card is valid
    And the dispenser contains cash
    When the customer requests cash
    Then ensure the account is debited
    And ensure cash is dispensed
    And ensure the card is returned

Of course there’s a high level order here:

Context
Event
Outcomes

But what about within the sections? Let's take a look:

Context

The Context is a description of the starting state: the things that must be true before we get started.

They are statements of "state", rather than "events".

This is an important distinction: events are slippery characters.

Because an "event" changes the universe is some way, the order of events tends to be important:

I put on my socks
I put on my shoes.

States are easier:

The sky is blue
the sun is shining
The birds are singing

Order isn't important.

These statements have the same property:

Given the account is in credit
And the card is valid
And the dispenser contains cash

They could appear in any order.

Event

What about the Event - or is it Events?

If we are dealing with more than one event, then the order of those events is likely to be important.

But in this particular case - the ATM Example - I couldn't seem to figure it out.

Requesting cash is an Event; removing the card is also an Event.

But what's the right order?

It didn't help that there seemed be be different sequences of events out there in "the real world":

My cash machine requires that I remove the card before the cash is dispensed.
But you told me that it's common for the card to be returned at the end.
And then there's the card dip, where withdrawing the card is one of the first things that happens.

The answer was staring me in the face. But I couldn't see it.

Implementation detail!

I went back and read Mike's post line by line. And found this perfect sentence:

“The solution design of the user interface should be left open to the development team to implement in whatever innovative or minimal way possible as long as the outcome meets desired behaviour.”

This like a slap to the head across the years:

IMPLEMENTATION DETAIL!

The How, What and When of the withdrawal of the card is an IMPLEMENTATION DETAIL!

The important event is the request for cash. For the purposes of this scenario, it's the only event we need to care about!

Outcomes

We have one more section to look at: Outcomes.

Account debited,
cash dispensed,
card returned.

Three events, right?

I'm going to go out a limb here and suggest that they are not events.

When I 'borrowed' this scenario, I dropped the word "ensure". I now think the work "ensure" is important.

Ensure that the events have happened.

If I'm right - and I'd love to hear your thoughts on this - this distinction means that we are dealing, not with Events, but with States.

It's the difference between saying:

I put on my socks;
I put on my shoes.

and

Verify that my socks are on;
Verify that my shoes are on

Applying the same transformation to our "outcomes":

Verify that the ensure the account has been debited
Verify that the cash has been dispensed
Verify that the card has been returned

Not only does this mean that the statements work in any order, but it also 'handles' the "card dip" case.

At the end of the "transaction", we verify that the card "has been returned".

And we find that it has.

That it was returned some time earlier... doesn't change that fact.

That is was returned some time earlier... is an implementation detail.