TDD vs BDD. The giants of test go head-to-head

Previously....

I tried to start a motorbike

That's a System Test.

And a Black Box Test.

It's also a Behavioural Test: a direct test of a behaviour that I - as the user of the motorbike - care about.

When my Behavioural Test failed, I checked for a spark.

That's a Functional Test.

No spark?

Perhaps the battery is flat.

Or the wiring is faulty.

Or the spark plug has failed.

Checking the sparkplug in isolation is an example of a UNIT TEST

At this point, the poor old Functional Test...

Got squeezed out.

Leaving us with the building blocks of today's main event.

In the blue corner: Test Driven Development

And in the green corner: Behaviour Driven Development.

Let's have a good clean fight.

Welcome to Development That Pays

I'm Gary Straughan

Today, we continue a journey that started three episodes ago.

If you missed any of them, you might want to watch them first - You'll find links somewhere around this video.

Now that we've looked a TDD and BDD individually, I thought it might be useful to take a look at them side by side.

This bout is scheduled for at least 7 bruising rounds.

Round one: Focus

Test Driven development is an inside out process.

It starts with a developer writing a single test.. and then write some code - just enough to get the test to pass Then another test and then write some code and so on an so forth.

The tests and the code grow and develop together. They're intertwined.

The testability of the code - is built in.

As is the quality.

Behaviour Driven Development, on the other hand, is an outside-in process.

The desired BEHAVIOURS of the finished system - the things that the end user will actually experience - are described up front.

And they're described by a set of Behavioural Tests.

All of which can, if desired, be written before a single line of application code.

When development begins, the focus is on getting the Behavioural Tests to pass

And since the tests relate directly to the Behaviours that the end user will experience,

the development focus is actually on delivering VALUE.

If TDD is about doing the thing right, then BDD is about doing the right thing.

Round 2: Writer and Reader

Who writes the tests?

For unit tests - which are written in code - the answer is clear: it's the developer

For behavioural tests, the plain english test format means that the tests can be written by the person that understands the customer best:

the Product Owner. Or the Product Owner and the Development Team.

Flipping the coin, who is likely to read the tests?

For units tests, a developer. A tester at a stretch.

For behavioural tests, it's almost anyone: developer, tester, product owner, business owner, stockholders.

Round 3: Speed

Unit Testing requires that components are tested in isolation.

In many case this will necessitate "faking" - or mocking - dependencies. This can be the trickiest part of unit testing.

But there's an upside to testing in isolation - with our without mocked dependencies.

The upside is that Unit tests tend to be super-quick to run.

With Behavioural tests we're always testing the system as a whole

The challenge here is putting the "putting the system into the correct state" in order to be able to run the test.

Everything in the "Context" section.

This setup - which may require a whole series of teardown and setup steps - has to happen before each and every test.

Not particularly difficult to do. But not quick either.

If a suite of Unit Tests take seconds to complete, expect the suite of Behavioural Tests for the same code base will take minutes to complete.

A clear win for TDD

Round 4: Specificity

Is that a real word?

We've covered this one before so I'll keep it brief.

When the motorbike doesn't start, I know something is wrong. But I don't know what is wrong.

When I test a spark plug in isolation - and the test fails -I know that the spark plug is what is wrong.

This is a key advantage for Unit Test. When a test fails, you know exactly what failed.

That's another round for TDD

Just as an aside, here's one for you to ponder:

You're responsible for a major system.

It has excellent test coverage, with a full complement of Unit Tests and a full complement of Behavioural Tests.

A major deadline is looming and you're gearing up for the release.

Vexingly, there's one failing test. And the dev team say they won't be able to fix it in time for the planned release

Question 1: do you go ahead and release to live?

Question 2: does your answer to question 1 depend on the TYPE of test that is failing?

We'll talk more about that - and continue with our main event - in the next episode.