Slowly But Sure with TDD
TDD (Test-Driven Development) is about driving development from tests. This is a software development approach where developer write tests first before they write the code. The basic steps of TDD is started by writing a failing test for a functionality that you want to implement. After that, you write the code to pass that test. Once the test passed, then refactor the code to ensure it meets the requirement standards of the code.
But, why TDD? What are the benefits from it? Doesn’t it just slow down the development process? At the first glance, yes I thought. As a back-end developer at my current project (which applies a scrum system), delivering a working software is something that I really try to achieve in every sprint. To reach that thing, of course I have to make the most of the sprint time. I have to be able to manage my time well, because in one sprint, my job are not only focused on the backend but also help the front-end team in the integration process.
So, the first thing that I do is create some tests from scratch. As someone who had never been practiced TDD, I swear this phase is the hardest part. To create test cases, we need to think about every perspective of the feature, identify all of the cases that will happen in the future, and also the potential errors. It took a long time for me to construct some test cases and make sure those test cases are really fits the design.
Once the tests were done, I committed them with a message “[RED]”. This message means those tests will make the pipeline fail because the actual codes haven’t been implemented yet.
After that, I realize that I had spent too much time on this things. The codes haven’t been implemented yet and there are still a lot of work to do. I was quite frustrated and this got me wondering if TDD was really the right method for me. Meanwhile, the clock is ticking and I have to be hurry. I continue my work by writing the actual codes.
In this phase, I wrote some codes with only one purpose, which is to pass all of the test cases. I felt like it was a little bit harder because I had to cover all of the test cases into those codes. After some failures, finally the codes were done. I committed them with a message “[GREEN]” and the pipeline were succeeded. codes were successfully passed the tests.
But, the codes were still not perfect. I had to refactor the codes to make them simpler, better, more readable, and maintainable. In this phase, we also had to make sure that our code doesn’t damage the functionality that they meant to give.
In my case, there was some code smells that caused by an unused parameters. So I removed them and then committed them with a message “[REFACTOR]”
In my project, I used SonarQube to check my code’s condition. After going through all of the processes above, here is the result.
After that, I tried to check my code with Postman to see whether the functionality was fulfilled or not. I tested the feature with various possible cases and it works very well without any bugs.
It amazed me! And at that time I realized that TDD was really helpful. TDD made the whole development process become easier. Although it took a longer time, TDD helps to ensure the quality by focusing on requirements before writing the code. By defining the tests at the first step of development, it helped me to consider what do I really need from the code. Since we define the tests first, there will be a reduction in bugs. It’s simply because the code that we created have already covered all of the test cases that we defined first. To create that code, the process may be more difficult. But at the end, it will be easier to rework on error and your code will be bug-free.