on
Why you should use TDD to build your app
To better code requires to be rigorous and methodical in testing. But it’s not easy to pick a test methodology. You may also ask yourself whether to write tests before or after development. TDD is a response to this questions. Discover an overview of this method through its fundamental principles, major advantages and some rules you need to follow to make good use of it.
“Our job is to tell you your baby is ugly!” – Software Testers
It should be obvious to everyone that testing is essential to meet quality requirements in any project. Therefore, you will most probably incorporate testing into your app in order to make sure it is working. However, it can be a huge drudgery for many developers who write tests. Without a good methodology, developers often test for testing, because the project requires it.
In these cases, testing is unfortunately seen as a millstone around one’s neck instead of a powerful tool. Often, we observe that it comes either from a lack of rigor in the testing strategy or even a nonexistent one. One of these strategies is called TDD, which stands for Test-Driven-Development.
What is TDD exactly?
Recommended by Google, IBM, Microsoft and famous developers like Robert Cecil Martin (better known as Uncle Bob), this methodology is to write the test before the code; That’s the deal! In this way, the tests done upstream will drive you to write [the right] production code.
To formalize the principles, three “laws” were enacted by Robert C. Martin:
- You may not write production code until you have written a failing unit test,
- You may not write more of a unit test than is sufficient to fail, and not compiling is failing,
- You may not write more production code than is sufficient to pass the currently failing test.
By applying these rules, you are going to enter a bugless and quality circle.
As a result, tests code and production code are written together all along the project, with a slight advance of dozens of seconds for tests. That’s why, if these rules are scrupulously followed, the code coverage will always be at 100% and it’s not the only benefit of TDD.
TDD’s benefits
Tests will drive you to develop and TDD will drive you to quality. First of all, without any surprise, it ensures that the code works and implements the requested features.
Also, it enables changes. Usually, developers are scared of changes. Why? Because every single change is a potential bug and can lead to regression. With TDD, you can run tests as often as you want. So every time you want to change, refactor or add something to your code, you are going to be notified if you have broken something. Tests become your safety net.
This methodology makes the clean and optimized code crafting easy. Indeed, the safety given by TDD preventing especially regression offers you the opportunity to clean and improve serenely your code. For TDD purists, this is its main benefit.
In addition, tests being written before the production code, it forces you to think ahead of time about the design and make choices such as classes, methods or attributes. Once again, clean code is highlighted.
Finally, TDD assists developers to be *focused only on the feature part** they are working on. How? Well, when the test is written, they know exactly what their goal is: passing the test, that’s it. We didn’t focus on the how for the moment. It’s only in a second time that he will improve the program clarity.
Of course, other benefits can be listed but we will still content with listing only these few.
You may see these multiple benefits as somewhat abstract, and it may be true for some of them. But given that this methodology was tried by companies on real projects, more concrete advantages were found and they are not the least.
Better safe than sorry
Regarding the density of bugs in production, TDD can easily reduce them from 40% to 70%. Also, bugs are detected at an early stage during the development phase. Obviously, the earlier you detect a bug, the better it is because if you keep developing, the software will be built on this bug. And it will definitely be more tricky to dig into the code and solve this problem.
Concretely, a bug fixed during the implementation phase is 16 times faster to be fixed than if it was found in the production phase. So instead of wasting 2 days fixing a bug, the developer who has cleverly decided to use TDD will only spend one hour on this issue.
The result of a good practice
While we have seen major benefits, there are also some areas of vigilance to consider. First of all, since the test code is close to the production code in terms of density, it is essential to keep it clean. Why? Because just like the production code, the test code must also be maintained to remain legible. With TDD, it should be easier to change the specifications of a feature and thus, easier to edit the tests. It is essential to have a clean code and a clean test.
“Tests are not a second-class citizen” - Robert C. Martin
But the TDD and tests are not always appreciated and are accused, often wrongly, of wasting time. It is true that an application will be developed faster without TDD, but it is not counting the number of bugs and anomalies with which it will be published. And the time that developers will spend to correct these problems may increase. Finally the TDD, which prevents these anomalies (up to 90% less!), reduces the time of resolution of bugs, and offers the ability to change serenely, should be considered as an effective time-saving.
The real cost to consider upstream is that of training developers to master the methodology. Once this is done, the TDD will undoubtedly save time, grey hair and money.