Continuing from our post earlier in the week where we described what TDD is and why TDD is critical. If you missed Why Test Driven Development is Critical Part I, you can check it out here.
Testable code is better code, code that promotes modularity, uses interfaces, doesn’t hide static variables, easy to understand, and easy to extend. If you are writing tests you will soon discover it forces you to write different style of code. This new style will make you a better developer just by the fact you think from the user side (can be human user or other server code consuming your services). TDD is responsible for that change as it is leading you towards the correct design. When things don’t test well, you think “can I write a better test (complex sometimes) or can I make my code more testable”. If you facing a problem testing something new, most likely you have a design flaw, it is time to think about your actual code, break it down and make it more modular and therefore testable. Like natural evolution process, your code evolves around the code as you progress with your TDD cycle, you always in a point you can improve what you already done while adding the new stuff in. You tests and your code keep evolving with each iteration, the tests are leading the way by forcing you to make better code to fulfil the tests.
It doesn’t really matter if you follow TDD or another practice, the point is you have to follow one that gives you the right tools to be a professional. The days of code hackers and large QA team doing regression tests day and night are long gone. If you are serious about being a great professional you have to become one, deliver quality code that works and sleep well at night knowing you deliver quality. The old days of monolithic code procedures are over, modern days style are changing rapidly and there is one thing that is emerging from the darkness, developer responsibility. You must take ownership of your code. It must work on any environment, and for any other team developer to compile it. You must predict the unpredictable and close any gap and block every hole. Your code is the best CV you will have, imagine going to interview showing off your beautiful code, that not only looks great but also fully tested. This is how you should feel about what you do, other team members will be able to look into your code, review your tests and understand your work without any documentations. It is that clear because you are a professional.
The most common reason for not using automated test is time waste, in people minds the fact you have to write 4 lines of test code for every line of production code seemed unreasonable. Consider the following, every line of untested code that has bugs in it waste time on a global scale (global as in beyond your own team time, company and client scale):
• Development teams – you never work in isolation, other teams may relay on your code, if they are consuming your services they are most likely to consume your new bugs. Facing problems they will start investigate the source of the issue and discover it comes from your code base, they will have to wait for you to fix it and waste time in a global scale
• Build team – Building a bad release but have no idea it is full of bugs. The build team wasted time on this buggy release only to have to repeat this process when bugs are fixed.
• QA team – Running same regression tests over and over again to discover bugs you could have found yourself. Running tests is time consuming and as your product grows, so does your QA efforts to try and cover all you have delivered and what still needs to work.
• Production deployment – Yes, you will ship your code late, bug fixes will be late and new functionality even more so. You always run the risk your code is not stable and production may have to roll back due to critical issues. Again, this is time wasted on a global scale. So when factoring it all together, writing tests is saving time for you and for the team.
On a personal note, before TDD I was just an average developer, testing my code randomly, hoping the QA team will catch all my bugs. I was performing the test manually from the front end, I had no idea how much of my code was working and where the grey area was between known and unknown. I had no certainty it is working. I was in the dark. I was also spending a lot of time running tests manually, because I had no automation so I was forced to repeat my tests and this was time consuming. More critically, my code was not great, even when I had an opportunity to improve it I wouldn’t because I was too worried I would break something else. If it wasn’t in the original design there was a small chance to refactor and make the code better. TDD gave me the framework to learn to become a better coder and overall professional.
Do you use TDD? We would love to hear your thoughts, so feel free to comment and share your experiences with TDD.