Reasons and Advantages of Using TDD – Test Driven Methodology!

Reasons and advantages of using tdd   test driven methodology

Through our last post, you should by now know what TDD – Test Driven Development is and today, we are going to discuss some of the advantages of this approach and the reasons why you should choose TDD. Here are a few for you to consider!


When we start the bug correction process, the first thing we usually do is try to reproduce the error, and then debug the flow where the bug occurs to finally analyze the status of the search objects in the root of the problem. When you do not have tests, you need to perform the steps of a functional test again to debug whereas if you write a unit test that "stimulate" the system to go through the faulty code, you are "playing" the error without having to run the application as a whole.


This may seem a somewhat controversial phrase, but it is not. The development flow in TDD is "Create tests before making the solution," This way you end up creating clean code that can pass the tests.


It is common to introduce a new bug while fixing the existing one. In other words, correcting a bug may have the side effect that a part of the software becomes inoperable. When this occurs, we say that the software has regressed. They are called "regression tests"; the test that aims to check the overall health of the system when a bug is fixed, or even when a new feature is implemented in the system. The use of TDD will reduce the introduction of the side effect along with the code changes. Of course, in TDD, only the part of the code that is covered by unit tests is catered. In addition, when a test fails to pass after a change, you only identify the bug in the close to when it was introduced.


The TDD encourages you to think before developing the solution and that you always create the simplest solutions. There is a very important phrase in TDD i.e. “If it takes many lines of code creating objects for a simple assertion, then there is something wrong." This makes you already know if you are going in the right direction to build the solution or if it is tightly coupled and must be modularized/simplified.


The tests help us document the system if we name it well. We think before coding and do small tests for each piece of the functionality i.e practically we are required to write a readable test. If we stop to see all the tests of a feature we have there practically a use case documentation.


As the TDD cycle itself suggests, the last step is refactoring. Then, for each test you write, look at the code again and if you feel uncomfortable there is a need too refactor it. The great advantage of working with automated testing is that we have the security to make changes because our tests are to ensure that our code will still work. Another interesting aspect is that refactoring every "green", we avoid unnecessary repetition which makes the code more readable.