Sh!t Developers Say: "We Need More Tests!"

Your Software Development Team has had a rough time of it.

They've spent the best part of a week tracking down a nasty bug.

And now they are feeling exposed.

They want to stop developing.

They want to s start writing tests.

They reckon it will take at least a fortnight.

The decision is yours.

What do you say.

Yes. Or No?

Not just hypothetical

This isn't just a hypothetical question.

I've been part of not one but two teams that said "enough is a enough",

and asked for the time and space to put things right.

• One team got a Yes.
• The other team got a No.

BOTH decisions were, in my view, wrong.

The Art of Motorcycle Maintenance

This is the motorbike I owned as a teenager.

Is wasn't the most reliable machine. It seemed I spent about as much time fixing it as riding it.

I had one key test that I'd do every time I came to ride it.

I'd try to start it.

I'd then go on to test...

Come to think about it: that was about all I'd test.

UNLESS it didn't start.

Then I'd do other test:

I might remove the spark plug and check that t I was getting a spark.

If the spark didn't look very healthy, I might check the spark plug gap.

Unit Tests

Checking the spark plug gap is a great example of a Unit Test.

It's a test of an individual component of a complex system.

Like all good unit tests, it's independent of the rest of the system.

(After all, the gap between here and here [the spark plug electrode gap] doesn't depend on anything else.)

System Test

Compare that with the test of "starting the motorbike".

A running engine requires a huge number of components - including the spark plug - to work together to produce a result.

The result being a running engine.

It's a great example of a "System Test".

It could also be described as a Behavioural Test.

A running engine is one of the behaviours that the "User" of a motorbike expects it to exhibit.

It could also be described as a Blackbox Test: we didn't have to gain access to the innards of the engine to perform the test. Indeed, we didn't have to know anything a bout the inner working of the motorbike to perform it.

All we need to know are (1) the inputs that need to be supplied....

• fuel on
• neutral gear
• little bit of throttle
• operate the kick starter

..and (2) the output to look out for:

• the sound of the running engine.

Functional Tests

Note that the very first test I mentioned - unscrewing the spark plug to check that I was getting a spark - is neither a Unit Test...

... nor it a System Test / Behavioural Test / Black Box Test.

It falls somewhere between the two camps.

Because I've unscrewed something, it's no longer a System Test (a test of the system as a whole).

Nor can it be described as a Black Box Test. (We've "entered" the black box.)

It's an example of a Functional Test: the expected "function" being the production of a spark.

As a test it's slightly unsatisfactory:

• A pass doesn't indicate that the engine will start.
• A fail doesn't indicate the root cause of the problem.

So a pass would lead us on to a System Test / Behavioural Test / Black Box Test.

A fail would lead us to a (series of) Unit Test.

Back to the Teams

I still haven't told you about the two teams - the teams where one team got permission to write tests and the other didn't?

I'll reveal all in the next episode.

But I will give you a big clue.

• One team asked to write Unit Tests
• The other team asked to write Behavioural Tests.

Talk to you next time.