TDD: The Unorthodox Way of Software Developing
Until now, there are still many pros and cons in the IT world regarding TDD. Many are of the opinion that we don’t have to implement TDD, but many also think that we should implement TDD. Which is correct? let’s discuss this in this article.
What are TDD and Test Coverage?
Test-Driven Development is a software development technique where tests are made to determine and validate the code that we will create after the test. So before we code our program, we have to make a test first. After that, we will create code that fulfills the test. The process at TDD has three stages, including:
- RED: red is a case where we just made a test for an implementation of code that hasn’t been created yet. So it’s just the test without the code.
- GREEN: green is a case where we have made code to fulfill the test we have made. So that it is complete with the test and code.
- REFACTOR: refactor is a case where we have done TDD until the GREEN stage, but there is something we want to fix so it is called a refactor.
Why should we use TDD?
Why should we use TDD? Maybe if it was explained in theory first it would be difficult to understand it. So I’ll give a real-life example first.
Imagine that you are working on a project with your team, and your boss has rules so that your test coverage is at least 90%. In this development, you do not use TDD implementation in your project. So, you code it first and then test it. Now try to imagine if you make code that is very complicated and in the end, the code is very difficult to test. Finally, you cannot do the test to meet the minimum 90% test coverage rule, so you and your team cannot complete the project. Of course, anyone does not want this incident to happen to them. Therefore, we have to implement TDD. Because by using TDD, we get a kind of guideline for what our code will be like. So that all the code that we create will be tested and covered.
The above is one example of the benefits of TDD directly in real life. Furthermore, these are the other benefits when implementing TDD:
Code coverage: In principle, every code segment a practitioner writes must have at least one associated test. Therefore, the practitioner can be sure that all the code in the system has actually been executed. Code is tested as it is written so that defects are discovered early in the development process.
Regression testing: A test suite is developed incrementally as a program is developed. Practitioners can always run regression tests to check that changes to the program haven’t introduced any new bugs.
Simplified debugging: When a test fails, it should be clear where the problem is. Newly written code needs to be checked and modified. Practitioners do not need to use debugging tools to find the problem. Reports on using TDD show that it is almost never necessary to use an automated debugger in TDD.
System documentation: The test itself acts as a form of documentation describing what the code should do. Reading the test can make it easier to understand the code.
How to implement TDD with Gitlab CI/CD
We can implement TDD very easily. We just need to follow the steps “RED-GREEN-REFACTOR” to do TDD. The following is an example of implementing TDD on my PPL project:
- Make a test first so that the pipeline on Gitlab is still RED
In the above picture is a test that I made before creating my code. After that, I do a commit with a format like “[RED creating test for <feature>”. After that, I push it to my GitLab. So that the pipeline results will appear as below which are still failed.
2. Next, we will create code that meets the terms and conditions of the tests we have made so that the pipeline in GitLab will be GREEN.
Above is the code that I created to fulfill the test I have made. After that, I did a commit with a format like “[GREEN] implementing <feature>”. After that, I push it to my GitLab. So that it will bring up the pipeline results as below which have been passed.
3. The last step is REFACTOR, which is an optional step to fix our code without making our pipeline failed.
Above is an example of the refactor that I created after adding the code to the application I created.
Conclusion
That is my explanation about TDD. So, the conclusion is highly recommended if you are building an application using TDD because it will make it easier for you to avoid bugs and make testing easier. Thank you so much for reading my article and hope it helps you! Adios!
References:
