is TDD testing?

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

According to Kent Beck [1] TDD is a bit nebulous, TDD is an awareness of the gap between decision and feedback during the programming phase. Beck mentions the gap between feedback and the program, aiming at the difficulty for programmers in having a quick response at the moment they are writing the code. Often the writing process by the programmer follows three basic steps: The first is writing the code, the second is testing and the third is refactoring in case something is wrong or there is a need to change the code. Here the hypothesis is created that with the evolution of graphical interfaces and the evolution of flows for carrying out tasks in the systems, the programmer is at the forefront of executing extra steps to get to the point where your code can be tested, thus delaying feedback if the code is working as expected and directly impacting late delivery of necessary changes to the software. The TDD mantra defined by Kent Beck follows three distinct phases:

• Red - First write the test code, thinking about how it must behave
• Green - Make the test pass with the smallest change possible
• Blue - Refactor, remove any duplicate code and make small improvements to standards

The first phase of TDD (red) is the first step to be considered by the programmer when developing with unit testing, for some it results It’s strange to write the test code before the “production” code. Production code is a term used for the code that will effectively build the desired algorithm to perform a given task. The barrier here is in a paradigm shift, which perhaps for those with more experience in programming more complex. Because with the years of the program accumulated, vices are accumulated and developed, making the experience of using a new paradigm costly.

On the other hand, years of experience can help the programmer to make this change, with experience comes mastery of a programming language and consequently the task of writing tests becomes less complex, as the focus will be on writing the code test, without the need to make external queries to resolve a syntax question.

Then comes the second stage of the cycle, writing the production code that does the test passes with the smallest possible change. It is important to highlight: “the smallest change is possible”, as this step focuses exclusively on having the test written by the step previous pass. This stage is what Beck defines as the baby step.

A baby step is the act of making a small change that achieves the goal as well as a baby’s steps, which are short but make the baby walk and reach his goal. Particularly the bay step phase is one of the most valuable techniques using TDD, changing the smallest part of the code necessary for the test to pass provides the programmer with a moment of self-reflection while programming.

Experience at this stage can also cause an undesirable effect on the cycle, as More experienced programmers tend to use a high abstraction. Even without the need for the same. This behavior is called over-engineering

The difference between TDD and unit testing

Difference resources refer to the practice of writing tests in different manners. This makes common sense difficult, for the subject at hand, the mix between unit testing and TDD is also present. For some, it is assumed that unit testing is done with TDD. But for me, the difference lies in how the code is written.

Doing TDD is not the same as doing unit testing, in fact, for me, the latter brings maintainability issues and is used to chase coverage purposes only. Whereas the former aims at providing a continuous feedback loop through test cases.

References

1. [1]Beck, “Test Driven Development: By Example.” Addison-Wesley Longman Publishing Co., Inc., 2002.