What is Test Driven Development?
aka TDD?
I'm glad you asked.
Welcome to Development That Pays
My name is Gary Straughan
First things first.
If we're going to talk about Test Driven Development, we first need to talk about the particular
type of test that underlies TDD:
Unit Tests.
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 I found writing unit tests to be hard. Damn hard. 10x harder than writing code.
Depressing.
I eventually discovered 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...
Wasn't like a spark plug!
Remember in the last episode we talked about testing the gap of a 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.
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.
My guess is that spark plugs weren't designed specifically to be testable.
I think it's probably the case that spark plugs were designed to be replaceable
and test-ability came as a very useful side effect.
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.
Test Driven Development - as the name suggests
is a process by which the tests are written BEFORE the code.
This doesn't mean writing all of the tests and then writing all of the code.
it's more subtle than that.
You start by writing just one test. A very small test.
Then you write some code. Just enough code to get the test to pass.
Then you write another small test.
Rinse and repeat.
The code and the tests are born and grow together.
The test-ability of the code is "built in".
Writing Unit Tests is easier for new code than for existing code
.But that's not to say that it's trivial.
There is a complication.
The key to a unit test is to test the "unit" in isolation.
If you saw the previous episode, I performed the following test:
I removed the plug cap, unscrewed the spark plug,
plugged it back into the plug cap
and operated the kick starter.
This was a test for spark, but it was NOT a Unit Test.
Because it's not a test of the spark plug in isolation.
(It's actually a test of a whole host of components working together.)
A Unit Test is possible. It just needs some additional equipment.
This device takes the place of the battery and a whole array of electrical equipment.
The device is assumed to be working,
so if there's no spark, we know that it's the spark plug that's at fault.
The software equivalent of providing this "additional equipment" is called "faking"
or "mocking".
To give you a quick example:
if I write a function to determine if the current year is a leap year,
I'm going to want to mock the date.
That way I can feed in a whole series of dates
And check/test that I get the right result.
Alas mocking isn't always so easy.
There are many real world cases where creating suitable "mocks" can be tricky and time consuming.
But the payback - and this is a key advantage of unit testing -
is that when a test fails, you know exactly WHAT has failed.
If this all sounds like too much like hard work
you may be interested to learn about Behaviour Driven Development.
Which, by happy coincidence, is the subject of our very next episode.
If you haven't done so already, I'd love to have you subscribe to this channel.
That way you'll be notified the moment a new episode is ready.
Click the big red button... and I look forward to talking to you again soon.