Table of contents
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 not to start with TDD, and I ask myself why they do that. Is there any reason for this? Maybe 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. Here are a couple of slides from my presentation, “Introduction to TDD (PHPUnit examples).” It may help you understand the TDD world combined with this post content.
RED
The first step is the RED, the most common, I guess. The color red in TDD represents 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. It is in the red stage as well where we do not write our source code first. Indeed, we will write our test first. The benefits of doing this are awesome, and we can enumerate a couple of them:
- Improvement of our source code design
- Prevent high complexity
- Get 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).
Finally, we have got our BLUE stage, also known as the refactor stage. Now we already have a test passing, and we know what we have to do to solve our problem, right? Let’s recap what we’ve done so far:
- We created a test and saw it fail
- 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!