Coding Best Practice #3: Test Driven Development

Until December of 2012 I had only vaguely heard about the term Unit Testing, in that JUnit framework and that it is very beneficial for development. The reason I am stating this is that, throughout my graduation and post graduation I had not learned about testing at all. I had nominally written some test stubs to test my classes, but the purpose was more demonstrative than testing each use case. So, it is strange to me that the coursework on software development left out such a crucial programming practice.

When I finally encountered unit testing, I could only wish I had known it before. The pile of code I had written in past, responding to the ton of half defined requirements coming my way and always having much intention to refactor it later, but never finding a safe way to do it.

If you are programmer like me working in a dynamic startup environment and possibly building version 1.0 of your software, Test Driven Development (acronym TDD) is what you must/should/aught to practice. Most startup softwares start with an aha moment where you intend to solve a specific first world problem with your cool new software. The process of bringing the idea to life is a lengthy one and needs to go through repetitive development efforts. Absolutely nobody can give you the whole picture of how software is supposed to look and behave in these early stages. And therefore there needs to be a way to make large and small changes to your code at all times.

The idea behind TDD can be stated by improvising this phrase: ‘lead by an example’ to ‘code by an example’. The process can be explained in five simple steps:
1. Write a failing Test
2. Write only so much code that is sufficient to make the test pass
3. Run the test and make sure it passes
4. Refactor testable code
5. Repeat the process for each new feature added to the code

As you can notice when doing TDD, adding each new feature starts with a test. The set of tests programmatically define how the software is supposed to behave. This is important because it shifts the focus from adding a line of code for each requirement to stating the requirement first. It also helps to recognize conflicting requirements and make suitable changes.

Practicing TDD makes your team smarter as well.

– The testable code has a natural side effect of being portable and can developed in parallel
– Unit tests act as a documentation of your code
– Anyone on the team can take on refactoring the code without hesitation as they have unit tests to protect them
– Unit testing along with continuous integration and gated checkins keeps source code deployable at all times
– Unit testing and constant refactoring reduces the technical debt of the team

Test Driven Development is an inevitable programming practice and needs to be followed by each programmer. Advanced development frameworks with inbuilt testing capabilities makes TDD a piece of cake. Pluralsight has bunch of modules to learn TDD from, which I encourage you to explore. Continuously testing the code and seeing the tests go green gives you the sense of satisfaction and faith in your program that every programmer strives for.