Test Driven vs Behaviour Driven Development

I tried to hang this shelf on this wall.

I made a mess of it. The shelf was wonky.

Could Test Driven Development - or even Behaviour Driven Development - have saved the day?

Shelving

A couple of episodes ago, I went through the process of hanging a shelf in what looked suspiciously like a Waterfall process:

• I did all of the measuring
• all of the transferring
• all of the drilling
• popped in all of the wall plugs
• and brute-forced the screws in.

Alas, the end result was not good: the shelf was not level.

But it got me thinking.

Could tests have saved the day?

• Is it possible to hang a shelf in a test-driven way?
• Is it possible to hang a shelf in a behaviour-driven way?

I think we should find out.

Test Driven Development (TDD)

Here's me hanging a shelf in my waterfall-like style.

Let's stop it... there.

Here's an opportunity for a test:

I could come back at any time and check that the line really is level.

That could be the first unit test.

More marking and measuring.

Stop there.

Lots of opportunities for unit tests here: one for each of these measurements.

What happened next? Oh yes...

I drilled all the holes. I popped in all the wall plugs.

Stop.

This is certainly a point where the unit tests could - and should - be performed.

But it's actually a few steps too late.

I've done far too much work between tests.

Lets rewind a bit.

Drill one hole (only). And perform the "unit tests" to ensure the hole went in in the right place.

If the test fails - if the hole has gone in the wrong place - now's the time to fix it: there's no point in continuing until all the tests pass.

Once the tests are passing, we can move on.

Drill another hole. Run the tests. Correct as necessary.

And so on until we have all four holes drilled - and tested.

In with the four plugs.

No harm in repeating the "unit tests"... but it's most likely that all would pass.

And we're now in a position to finish the job.

In go the screws.

Unfortunately, it's no longer trivial to run our unit tests.

But there is another test we can run: we can check for level.

And given that we've had "green lights" up to this point, the chances are that this test will pass too.

And it does. The shelf is perfectly flat.

Behaviour Driven Development (BDD)

So much for Test Driven Development; what about Behaviour Driven Development?

A shelf is a bit passive. It doesn't have have much in the way of behaviours.

But if we are generous with our definitions, we could say that a desirable behaviour is that anything that are put on it should not slide off.

Or put it another way, the shelf should be level.

It can be argued, then, that testing the shelf for level is not only a unit test; it's also a behavioural test.

In the sequence we've been through, this "behavioural test" was the last thing that we did. AFTER all the work had been done.

The very opposite of "behaviour driven".

Is behaviour driven development even possible in this case?

Turns out that the method my dad used to hang a shelf looks a lot like a behaviour-driven process:

First step is marking the centre of the shelf.

We could have a test for that - to verify that the mark really is in the centre of the shelf. That would be a unit test.

(It's the first and last time we'll come across a unit test in the sequence.)

Moving on...

Check for level. That's the behavioural test.

There it is again.

This time it fails.

Again, no point in continuing until "all the tests are passing". A quick tap with a mallet.

Run the tests again - this time passing. Which means we can move on.

There's the behavioural test again. And again one final time.

Success!

Would you believe it:

It is possible to hang a shelf in a test-driven development way.

AND its also possible to hang a shelf in a behaviour-driven way.

Which is better?

I have my opinion... but I'd much rather hear from you.

Please take a moment and let me know in the comments below.