A few years ago, I worked on projects where the code was not designed using Test Driven Development. We all make mistakes but at least something good comes out; we learn from past mistakes. But now it’s quite clear, I have come to the conclusion that the best way is to do TDD.
I sometimes (as everyone) have problems in communicating a functionality to the team. If you don’t watch what I’m doing, I can even do more than what is needed to bring a functional increase to the end user. So today, to be more productive, to do it faster and to generate less bugs, I truly recommend to do TDD.
I still find myself working with people that don’t do TDD or that don’t even know what it is. Developers that work without knowing exactly what your program does in a given site. I am not here to criticize, don’t get me wrong. I understand that although for me, my arguments are obvious, for others it may not be.
What is TDD and how does it work?
Test-Driven Development is a way of writing software. It’s important to know that usually this approach is commonly used by companies that follow Agile principles. The idea is that before adding a functionality, you write an automated test about how this new functionality that you want to introduce to your system (new code) has to behave. You then run the test and you wait for it to fail, yes, you make sure that it fails. You then again update the functional code to the specification, you write the simplest code, for it to pass. You run the test again and you make sure that this time it passes. At the end you have to refactor (even the simplest code has undesirable properties) and make sure that you have a clean code.
14 reasons to do TDD
- Avoid over-engineering. Over-engineering is a common problem that many developers face. As it’s name says it, it’s when you over do it. It refers to the fact that not all the pieces of the code contribute to the requested functionality and are therefore not necessary. TDD helps programmers to keep focus on exactly what they need to build, do not fall into over-engineering!
- Feedback from my API. TDD helps you get fast feedback from your API, much quicker. This fast feedback guides API design and there is no need start the tests from the beginning, its cumulative, you don’t need to do all the layers. Time saving!
- Great documentation. TDD is the most effective way to communicate and it also serves to keep a “record” of what you were thinking during the development. Test methods give a clear picture of a particular function, what goes in and what comes out. When your are facing a code generated by another, you go straight to tests to see what the code does and it’s responsibility in the overall system.
- Emergent design. There is no need to know exactly how will be a class or function. Of course it’s better to have information, but this doesn’t mean that your design will be mature enough to respond well to change. The process of refactoring makes your design grow to where it has to grow.
- Independent interface. To avoid contaminating the design decisions about API, you better know the “contract”. Without this, the power of object-oriented programming does not exist. I speak of polymorphism and modularity, ‘I‘ from SOLID (segregation Interface) interface or separately.
- Better communication. TDD helps communicating to colleagues what is the problem that is being solved.
- Get tranquility. TDD enables you to touch any project without the fear of being wrong, because it breaks it all.
- Refactoring. The definition of refactoring is to simply change the design of your application without changing the functionality. Since the function is under test, doing TDD is the only way to ensure that after changing the code everything works as before. I have not seen any faster and safer way to do it.
- Debugging. TDD is the best way to fix a bug. First thing is to do a test to reproduce the bug. Once you have that, it’s quite simple and the bug does not come back up to prod because it will have coverage test.
- Functional scalability. As my application grows in complexity, costs increase and time-to-market is lengthened. If you don’t do TDD, you will reach a point where it will become unfeasible to keep all the code. The complexity also makes the understanding of the components difficult.
- Learning. TDD helps team get better. I have watched my team work together on testing and I have seen them grow so much.
- Customer Satisfaction. Do not forget that we always have a product owner or customer waiting for something that works, TDD works.
- Agile Development. With automated tests, you get quick feedback and other benefits; during the construction of the project we know whether building something breaks or not. This allows us to successfully implement Continuous Integration. Our cost of preparing the project to be built goes to zero.
- Improved integration with third parties. When you have everything under tests, we suffer less to integrate with 3rd parties. Merging is less expensive and many hours are saved simply by doing TDD.
At the end, many people want to do TDD but they say it’s hard to find the time to do so and use other excuses not to. What do I have to say to that? No more excuses. Don’t bother yourself anymore and do TDD right now. A senior developer is bound to be decisive, however the environment is, even in hostile environments. If you want to be more productive, just do TDD.
Hopefully these 14 reasons to do TDD convinced you. If you have other benefits of TDD don’t hesitate to add them into the comment section!
If you enjoyed this read and would like to stay up to date with our latest news, you can always subscribe to our monthly newsletter!