Test-Driven Development is a concept I learned a while ago. But ever since I learned about it, I always thought of it as a theoretical concept that I didn't bother practicing or even give a try. The fact that I had no systematic approach to follow while developing projects, played a big role in not practicing TDD at all since most of the projects I had worked on so far were personal. My codes used to get tested every time users interact with my software, whether it’s through an application or part of an API. The unfortunate reality is that by the time the code is in the hands of users, it’s too late to find out that it doesn’t work.
Soon after Joining Andela's fellowship program. I learned that we test code during development, after development, right before releasing the code to users and even right after releasing. At each step, it’s possible we could find a defect in the code and need to fix it. The later the defect is found, the larger the impact it has on the project. It is for these reasons that the code should be tested at each step, in order to ensure that the code does what it is expected to do. That’s when TDD comes in.
TDD is a repetitive process used to ensure the quality of the program that's being developed. TDD helps a lot especially in defining the desired standard of the project and helps to ensure that those standards are met throughout the whole development cycle. Initially, tests are written before any function with the purpose of failing, then functions are built from thereby improving in order to meet the acceptance criteria. Tests should be run consistently until they have passed before moving to the next functions’ development.
Now that I have been introduced to TDD, and I have realized how important it is especially in the corporate world, I have started practicing it on my projects. I have gained a lot as a developer, by writing code to find bugs as early as possible. Although having tests doesn’t make bugs disappear completely, but it does reduce the frequency of them, along with ensuring that changes you make don’t have unintended side effects.
Test-driven development (TDD) is a development technique where you must first write a test that fails before you write new functional code. TDD is being quickly adopted by agile software developers for the development of application source code. TDD does not replace traditional testing, instead it defines a proven way to ensure effective unit testing. A side effect of TDD is that the resulting tests are working examples for invoking the code, thereby providing a working specification for the code. My experience is that TDD works incredibly well in practice and it is something that all software developers should consider adopting.
By concluding, TDD can only be successfully practiced through writing tests as if they are requirements, then write codes to satisfy the requirements. Unless it is frequently practiced, It is hard to do it in real life but it is worth the hassle. Most of us junior developers, we are reluctant to implement it because we believe that our old way of developing does it. So it makes us feel like there’s no need to practice TDD. But the sooner it is started to be implemented the better.
Top comments (0)