Before I read the book by Kent Beck I was just thinking - pesky tests what are they good for apart from getting in the way? What’s so good about Test Driven Development?

But writing tests isn’t what test-driven development is about. It's actually about designing your code in a way that matches your expectations. It's a powerful technique that, when understood, will transform the way you write code and design software.

NOTES

Kent Beck - Test Driven Development By Example:

https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530

Github template repository:

https://docs.github.com/en/repositories/creating-and-managing-repositories/creating-a-template-repository

QUOTES

00:54 - "Because TDD is not about driving development through testing. It's about designing and architecting your application. Through writing tests." [RB]

02:12 - " I find myself going backwards and forwards, making sure I understood every single step and what it meant in that first section." [RB]

03:26 - "And so you carry on writing some more code. And eventually the whole thing becomes a great big ball of string. Lots of code and no tests." [RB]

04:06 - "It's more of a tool for a structured approach to design in the first place. " [RB]

05:07 - "Writing a test helps show that it works. In fact, the word test is really wrong here. It's more of a proof than it is a test." [RB]

06:06 - "Writing code in TDD can initially feel slow and labored but in only a short time, you'll start to notice the benefit." [RB]

06:36 - "This is almost like the reverse Conway maneuver to Goldratt's theory of constraints." [RB]

08:02 - "Whatever we do, there has to be a low barrier to entry for testing." [RB]

08:42 - "And this is the true power of TDD, rather than agonizing over design and architecture and advance" [RB]

09:12 - "TDD is an absolute no brainer" [RB]

Hi, this is the software that every club, episode 22.

I'm your host Richard bound.

And this week, I'm talking all about the power of TDD, the

power of test driven development.

So what's so good about TDD.

I think before I read the book by kent back,

I was just thinking pesky tests, what are they good for

apart from getting in the way?

What are they good for?

Perhaps for proving we have control of our software.

Often we written it.

That we have thought about it and decided that we can automatically

prove works and is deployable.

perhaps the image problem that I've had with the idea of tests in the past.

And that there's something that you have to do after coding in order

it was to prove that it works.

this really isn't what test driven development is all about.

Maybe this is a misnomer of TDD test-driven development does not

describe what it's all about at all.

Maybe instead it should be called design through testing.

Because TDD is not about driving development through testing.

It's about designing and architecting your application.

Through writing tests.

There are lots of pluses to this technique and not many

drawbacks that I can think of.

Because it improves your design helps you get unstuck when you need help.

Plus, you've got your test passing and through refactored

and your code is written.

So you've done everything.

Sounds good.

Right?

So, what does this look like?

Sometimes when you're building an application, especially if it's on and

off, you're not doing it full time or perhaps you're distracted by production

support, or you have to do other things.

Perhaps it's an open source project.

It can get to a point where you can't see the way forward.

Or perhaps it's a case that when you come back to the code, you've

forgotten what it's supposed to do.

So how can TDD help with this?

If you've read the book, test driven

development, by example, by Kent Beck.

Then at first it might all seem a bit obvious or perhaps a bit daunting.

It's written in a chatty style, which may not make it the most obvious or

easiest to follow in the first instance.

It does require some work.

You should get invested in the story a little bit.

Once you do that and take your time with the exercises, particularly in

the first parts of the book, then it will pay you back for your persistence.

I find myself going backwards and forwards, making sure I understood

every single step and what it meant in that first section.

After a while it clicked for me.

What I saw that this was a really clever way of designing code.

And not just a way of making sure we have good code coverage.

The first part of the book will tell you everything you need to know

about TDD and why it's so powerful.

The second part extends this knowledge without other paradigms.

And the third gives you plenty of great examples.

So, what does TDD do that is so different?

If you're a programmer already, then you'll already be familiar

of being in a coding zone.

Perhaps when you put on your favorite least distracting music and you climb into

your editor and your code excitedly, and you write and you write and write, and

perhaps you test manually as you go along.

But you don't formalize any of those tests, at least not straight away.

You might grudgingly add some tests afterwards, but perhaps they're

quite high level and abstracted.

Perhaps you're kind of trying to scam the testing gods.

And you're not too close to the actual core business or the domain language

at the heart of your application.

Then perhaps you come back to it later.

And you want to get that coding feeling again.

So you jumped straight back in.

So the coding you want that coding high.

And the coding high comes from writing the code, not the test.

And so you carry on writing some more code.

And eventually the whole thing becomes a great big ball of string.

Lots of code and no tests.

And you're not even sure what the original intention was anymore.

So we're coding happily.

And perhaps we end up in a blind alley and have to unpick our work,

or sometimes even start again.

This can feel like we're making progress, but not all the time.

For solo coding, this can definitely happen.

coding as part of a team, then this is less likely to happen

because you do need to justify your code and your design decisions to

othersthat you're working with.

So TDD is therefore perhaps only useful for solo coders you may think.

No, because it's more than it's all for just not getting stuck with a design.

It's more of a tool for a structured approach to design in the first place.

By taking your time with testing and design as you go you make

it clear for everyone who works with the code in the future.

So how does TTD differ from the code first or even a design first approach?

Well, you write the test first and then you were tray one minus the time.

To get passing tests.

So you need to keep passing your test.

As your north star.

And without that indication, you just don't move on.

So immediately TDD imposes a discipline on your coding.

You can't any more, just keep writing code and hope that it works.

You need to prove it to yourself at every single step

. How does this help with your design and

It sounds like it might be boring.

It sounds like you might miss something important.

And you're worrying about tests so how can this help?

This is in fact, one of the key benefits.

Proving the what your building will do.

The thing that you're intending.

Writing a test helps show that it works.

In fact, the word test is really wrong here.

It's more of a proof than it is a test.

It's proving that the thing you've created will do the thing that you say it well,

And the cool thing about this.

Is it the test or proof makes you think more deeply about what the code you're

going to write is exactly going to do.

You're creating a specification for your code to fit into.

And that specification means two things.

When you do write the code, it virtually writes itself.

And when you've written the code, you can tell immediately if it's

working by running the test.

And this covers the first two important mantras of TDD, which are right a test.

Then write the code.

The third important mantra.

And the discipline is refactor.

Ensure that the code is not only doing the right thing.

But doing it in the right way for the rest of your code for the rest of your

design for the future of your application.

Writing code in TDD can initially feel slow and labored but in only a short

time, you'll start to notice the benefit.

Not only because you have a lot of tests.

But also because you'll have an emergent design.

The design itself comes from creating tests and thinking about what your

code would do before you write it.

You're creating your expectations as specifications about what the code can do.

By approaching this through constraints, we help our brain focus on what we intend.

This is almost like the reverse Conway maneuver to Goldratt's

theory of constraints.

We add a constraint, then we solve that constraint by fixing the functionality.

Step-by-step we constrain our domain.

We constrain our functional model.

And we constrain our application to be the thing that we intended to, but I've

never actually described to this point.

Okay, before I get too philosophical about this.

How can we do TDD practically?

Well, it's important that you have a project in source control.

A build system and a way of running tests against your projects.

So with a source control system.

You can baseline all of your changes.

If you don't have source control, then we can't be sure that we're

doing the change we intend.

Secondly, a build system is needed.

Obviously, we need to be able to compile a code to validate

that it's syntactically correct.

And then finally we need to test framework.

Sometimes it's built into the language or natively supported.

Sometimes you need to find a framework that you can use with your build system.

Once you have these three things.

That it makes sense to invest also in some automation that your tests show, you can

run your test manually, but after every change, do you really want to do this?

Perhaps sets up your CI to run tests every time you push.

Also I'm currently working in a rust and with vs code has got a nice feature

where you can just click on the test in the code and run it from the editor.

Whatever we do, there has to be a low barrier to entry for testing.

You want to be writing tests and running tests continuously as you code.

Therefore it needs to be simple and as automated as possible.

So there is some upfront work here to set up your project with a testing framework

but this will pay you dividends when it comes to creating something new.

When it comes to you creating your design.

So perhaps in your source repository, you can even create a template

project that is ready to go.

Again, the barrier to entry, it needs to be really low.

ideally, so that when you have the idea, when you want to try something out new,

you can immediately create your projects and start designing, start creating.

And this is the true power of TDD.

Rather than agonizing over design and architecture and advance.

You can just see what flows from your mind whilst constraining yourself to

focus on one piece of functionality at a time, one aspect at a time.

Right a test.

Write the code.

Refactor.

Red green refactor and then green again.

Piece by piece.

You will create something that not only more closely resembles

what you intended to build.

But also has a great code coverage already built in.

For me, TDD is an absolute, no brainer.

If you've not tried it yet.

Then what are you waiting for?

That's it for this week.

Nice and short and sharp.

I'm in the middle of writing something fun using TDD.

So I need to get back to it.

I wish you luck check out the book until next time.

Goodbye.