In short, TDD (Test-Driven Development) is a software development methodology centered in a cycle that can be represented by these steps:
- Writing tests.
- Writing code that makes those tests pass.
- Refactor or cleanup the resulting code.
However, there’s more than just that. Also frequently called Red – Green – Refactor, the test-driven development methodology is an acquired taste, and for people who say “coding is my life” (like me), it’s a life choice.
Software is a live organism, it changes just as much as the human body renews a large part of its cells every 10 years, so how could we dare to maintain and enhance such vast complexity at the same time we make sure it does not lose quality and stability? Well, of course, by applying lots of design principles, but also by making unit tests the star of the show, not a secondary character that disappears in a few episodes.
It is true that anyone with programming skills can write a program and make it run, while it’s enough when doing some programming (not software engineering), it isn’t enough in real life. This means that, when you enter a development team, your code is expected to not just do what it’s expected to do (and not anything else), but also to be dependable and efficient. These things are not usually accomplished in one iteration; it takes time and dedication to produce quality software, and this is where test-driven development shines. Why? Because building software with TDD is like building a skyscraper: You lay down foundations, then build floor on top of floor and the only thing preventing the skyscraper from collapsing while you’re building it, is the stability of the ones you already built. This is the key in TDD. You don’t start writing code; You start by knowing the product and the business logic behind it, then you identify the key goals you need to accomplish – which will also help you task out your work – and then, when you run the tests for the first time, you have your challenge: Writing the code that ticks all the boxes.
Some developers think TDD is slower than just starting coding, but the truth is, TDD will save you vast amounts of time as I learned over time. Let’s paint a picture to explain: Probably a good example of non-TDD is when you realize you need to make a change in your original strategy. So, you make the changes and run your code, test it yourself again and again (wasting time and brain cells), then you go ahead and cover it with tests when you’re already tired (awful). Now, If you practice TDD, you’ll be covered from day one, and each change you make to the code, will just have to pass the tests, tests that you will run while making progress on some other parts of the code. This will enable you to multitask, work smartly and more efficiently, having the desire to clean up your code again and again because it only takes a keystroke to run your tests and verify that your changes work as expected.
As a rule of thumb, you can follow the following TDD guidelines that I took from this post which I found interesting:
- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
As you can see, TDD is all about focusing on modular parts of the code, for which you write a single unit test, then make that piece of testable code work the best way possible before you take on the next challenge, this is another great thing about TDD, because by principle, you divide and conquer, breaking big problems into small ones and tackling them one at a time.
At the beginning of this article I mentioned that TDD is a life choice, and it is, it’s just like when you learn about software design principles, you simply won’t go back to the time you didn’t know how to produce quality, stable, dependable code, and it’s the same with TDD, I encourage you to try it, you’ll thank me later.
Thanks for reading.
Pablo Romero
Senior Software Engineer
