ARE YOU NOT USING TDD?! - PART 1

The content here is under the Attribution 4.0 International (CC BY 4.0) license

I’ve been working with TDD for a while and every day I see developers creating excuses to not start with TDD, and I ask myself why they do that. Is there any reason for this? Maybe the procrastination and the fear of new challenges come to mind. TDD has a life-cycle to follow and here I’ll try to show how to get started with. Here are a couple of slides from my presentation “Introduction to TDD (PHPUnit examples)”. It may help you to understand the TDD world combined with this post content.

RED

The first step is the RED and the most common I guess, the color red in TDD represents the failure. I have had a lot of bugs found in my code before I adopted TDD because I used to think that piece of code works but, I forgot to test what I’ve done with different inputs, different scenarios and so on.

The red stage as we go through will show us many scenarios and many cases where our code will have a little bug. Is in the red stage as well where we do not write our source code first and indeed we will write or test first. The benefits of doing this are awesome and we can enumerate a couple of them:

1. Improvement of our source code design
2. prevent the high complexity
3. Getting confidence with our source code

GREEN

The green color is a perfect clue to the red after we created our test and saw it failing now it is time to pass it and make it green!

The rule here is do not make a complex algorithm instead we will make it pass as easy as possible and by that, I mean with hard code. It seems weird at first but everything will make sense in the blue stage of TDD where we will do some code refactoring.

The goal of the GREEN stage is to make the test pass and not the best way to solve your problem or to create an amazing snippet instead we are trying to achieve the simplest solution to see our desired green (our test passing).

REFACTOR (BLUE)

Finally, we have got our BLUE stage known as the refactor stage as well. Now we already have a test passing and we know what we have to have to solve our problem right? Let’s recap what we’ve done so far:

1. We created a test and saw it fail
2. We fixed the code to make it pass with hard code

Nowadays programming hard code is not a good practice and worse it will not solve your problem correctly so now is the perfect time to refactor the hard code and think about the best way of solving your problem, but of course without breaking your test.

The test passing is our safeness to refactor and improve our source code without side effects. Here we reach a great benefit of TDD, refactoring without fear. Before TDD I used to change some legacy code to fix a bug or to improve the code but in a few weeks forward after my change in the code I had a new bug to fix caused by my change.

Wrapping up!

This is the first post of a series about TDD. I presented to you the life cycle of TDD and how to understand each stage of it (red, green and blue).

To get deep into the TDD work I’d recommend the book TDD by example by Kent Beck (examples in Python and Java), a quick read in SOLID principles and finally try to find some material of TDD in a programming language you are familiar and do not give up!