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

Welcome back to our deep dive into Software Testing.

Today the focus will be on Unit Tests and Test Driven Development.

If you missed the previous episode, there should be a link to it on or around this video.

Assuming you're all caught up, let's get started.

Impossible to test?

I first came across unit testing in about 2008

By that point, I'd been developing full time for a few years. I thought I had it down.

But writing unit tests was hard. Damn hard. 10x harder than writing code.

Depressing.

I discovered over time that it wasn't my fault. Much of the stuff that I thought was impossible to test....

... really WAS impossible to test.

It wasn't me after all!

Why were the tests impossible to write?

I was trying and failing to write a test for something that was not like... A SPARK PLUG!

Remember we talked about testing the gap of the spark plug. That's a perfect example of a unit test.

Another perfect example would be a test of its resistance.

With the right equipment, we could even perform a unit test to confirm that it sparks.

Test-ability

All of these tests are possible because there's something special about a spark plug

It's... TESTABLE!

By design, it can be removed from the engine.

It's one of the few things in the world that has a (more or less) standardised tool for removing it.

If you have a socket set, the chances are that it includes a spark plug socket...

and the chances are very good that it fits the spark plugs on your car, your motorbike - even your lawnmower.

Now I'm not sure if spark plugs were designed to be testable. I think it's probably the case that spark plugs were designed to be replaceable...

and testability came as a very useful side effect.

Testable - by design

It's been my experience, that things rarely evolve naturally to be replaceable/testable. They are replaceable/testable by design... or not at all.

Nowhere is this more true than with software.

I can say with a high level of confidence, that if your codebase does not have unit tests.... then your codebase consists largely of UNTESTABLE code.

Which brings us nicely on to Test Driven Development.

Unit Testing

I thought it mean that your wrote all your tests ... and then started writing your code.

If fact, you start by writing a FRACTION of a test.

Then you write some code.

Then you write a bit more of the test.

Rinse and repeat.

The code and the tests are born and grow together.

The testability of the code is "built in".

That's part of the payback for the (marginal) additional effort.

There's more payback in the the test will now be executed hundred, thousands or even millions of times.

(Many developers have things set up so that ALL the units tests run EVERY time they hit the save button.)

Team update

Remember our two teams?

As I'm sure you've guessed by now, the team that asked to write tests... and got their wish...

had asked to write units tests.

We spent two weeks battling with untestable code.

Tests were produced... but most were test of things that were easy-to-test, rather than things that were IMPORTANT to test.

Our time would have been better spent on writing a different kind of test.

A kind that can be applied to any codebase.... no matter how "untestable" the code may be.

... and that's what we'll be looking at in the next episode.

Talk to you then.