Already some years ago peak line project in which the code was not designed using Test Driven Development. Yes. With a few years ago As I keep making mistakes and still costs me validate my design, so the best way that I have at this time is to TDD. Perhaps there will be another way tomorrow. Nowadays I still have not found.
Yes. I still have problems in communicating functionality to the team and if I do not watch me, I tend to do more than you need to bring a functional increase to the end user.
So at this time, to be more productive as quickly as I know, the faster and generates fewer bugs me is doing TDD.
Every day I still find myself with people who do not do as I do. Developers who work without knowing exactly what your program does in a given site. I understand that although my arguments are obvious, for another it may not.
So to expose some of the reasons for TDD, as said in a post on Facebook someone of the caliber of Kent Beck, here are some reasons:
- Do not fall into the over-engineering. Over-engineering is a problem that exists and is very common. Typically, most of the lines of code in an application pikes not be used or are not necessary. Make that “you pass the test” test putting that green, helps implement enough. TDD helps maintain concentration and focus.
- Feedback from my API. I have to find a new way to get quick feedback on my decisions when designing an API. This does not have to do all layers or waiting for nothing more than to make the contract of a component that is dedicated solely to something.
- Documentation. Long ago I did not generate documentation. Not because it is not needed. TDD is the most effective way to communicate as expected the API to use and also serves to keep what you were thinking during development. Test methods, give a clear picture of what a particular function, what goes in and what comes out. When I face first with a code generated by another, I go straight to tests to see what it does and what its responsibility for the overall system.
- Emergent design. No need to know exactly how it will be a class or function at the time when the spades. Better to have information, I do not say no … but do not even because they have all the information if your design is mature enough to respond well to change. The process of refactoring after having the green makes my design grows to where it has to grow, nothing less. If it was not for this I would not be so structured design.
- Independent interface. To avoid contaminating the design decisions speculating about to do my API, you better know the “contract” or “that of which it is responsible for a class.” Without this power of object-oriented programming does not exist. I speak of polymorphism and modularity .. ‘I‘ from SOLID (segregation Interface) interface or separately or role.
- Communication. TDD is the way to be required with my colleagues on what is the problem I am solving.
- Tranquility. Having a button “Is everything OK?” Is something that now I can not give without compromising the stability of my work. Touching any project without fear of being wrong (because it breaks all) helps me go faster.
- Refactoring. The definition of refactoring is to simply change the design of your application without changing the functionality. Since the function is under test, do 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. When a bug (which coincidentally happens in those parts of my application where no test) TDD is the best way to fix the bug. The first is to do a test to reproduce the bug, specifying as always, you have to return that function. Once I have that, it’s as simple as implementing green to me. This bug does not come back up to prod because from that moment has coverage test.
- Functional scalability. As my application grows in complexity costs more out functionality and time-to-market is lengthened. If it were not for that I do TDD, come a time that would be infeasible to keep all the code. The complexity also makes the understanding of the components becomes difficult.
- Learning. Since less time employment “make it work and not break,” have more time to study and learn. By doing TDD my team has grown professionally and difficulties go from being the design or implementation patterns “will implement an input queue with Akka-Camel.”
- Customer Satisfaction. Do not forget that we always have a product owner or customer waiting for something that works. Now we focus on functionality rather than take what needs fixing.
- Agile Development. Because automate tests, have quick feedback and other benefits, we have the automatic construction of the project and know whether to build something breaks. This allows us to successfully implement Continuous Integration. Our cost of preparing the project to be builded has been zero.
- Improved integration with third parties. When you have everything under tests, we suffer least integrate with other repositories. The merge is much less expensive and discuss many hours saved simply by doing TDD.
In the end, many people want to do TDD or wants to “prove” but hard to find the time and excuses are provided. No more excuses. Everyone has the same problem of lack of time, the rush and the project manager will not let you or CTO says you do not need me … Eliminates the “no … but I’d love to … .. “from your vocabulary. Some people even with these difficulties get it but some people do not. Do not be those who can not.
A senior developer is bound to be decisive, whatever the environment, even in hostile environments
If you want to be more productive, do TDD RIGHT NOW. Not tomorrow or when you “have time”. Don’t keep bothering and do not blame with the same excuses that everyone says. You have really much to improve yourself in exchange for very little (or a lot … anyway) effort.
