As the topic says, this post is going to mention why Test Driven Development (TDD) is important. The answer is simple because I love it. I am writing this post in the first place because I am a big fan. Different people have different opinions. At the end of this article, it’s you who have to decide if you want to follow it or not.


What is TDD?

TDD stands for Test Driven Development. Wikipedia says, “Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first, the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.”

So, your code should pass the tests. But why should you do it ? Doesn’t the team have a QA who can do it? Why should you as a developer waste time doing this? These are the questions most of us had when we started doing TDD.

Eventually, I found answers to my questions which I am going to tell you and like I said, it’s you who have to decide.

You should do TDD for:

  1. Guarding your code: Consider a complex piece of code you wrote and handled a corner case with some logic. After a week, a senior developer asks to refactor the same, or a junior comes with a bug which requires modifying your code a bit. What if during refactor or bug fix, they miss the corner case. Your code will be considered the culprit for the feature that broke because of that missing case. What if you wrote tests for it. When the other developer runs the test cases, that particular spec fails and hence he makes sure that he doesn’t break that case and thus anyone won’t miss the corner case . The failing test tells him that he screwed up something. This way the code you wrote is secure. Tests guard the feature you implemented.

  2. Effective bug fixing: The same applies to you when you mess with other’s code. You can fix your bug and then make sure that your fix didn’t result into a regression, make sure that it passes all tests.

  3. Maintaining good code: Of course, to write tests for a piece of code, you need to write testable code. Testable code by default is a quality code.

  4. Easily identifying bugs: As mentioned above, a breaking test is an indication that something is wrong, and the code is not ready for shipping. It’s better to fix the bugs before they go into production rather than patching minor fixes or living with major bugs.

  5. Minimize regression: Your QA team might be wasting a lot time doing regression testing. Of course, test cases minimize regression, how? Because your test cases make sure that you do not introduce any regression. 

And the list goes on. You will discover many other benefits of the process as and when you get into this habit.


How to do TDD? 

  1. Write few test cases that defines a desired improvement or new functionality. Have at least the basic cases covered and keep adding more as and when you figure them out. Let them fail initially.

  2. Code the scenarios which have test cases and make them pass. Do this for the changes made in both code and test cases.

  3. Finally, refactor both test cases and codes to acceptable standards.

  4. Make sure that you don’t break any existing tests. Eliminate irrelevant cases, add new ones and modify existing ones. Keep improving.


CONTINUOUS INTEGRATION

Run the tests before deploying them to the servers and if the tests pass, then it is a good sign of healthy code and a green signal for the deployment.

It is always better to fetch code and run the tests after every push to the code repository to make sure that even a small change hasn’t broken anything. And once the tests pass, the code can be deployed and be ready for QA team to test several features in the app(of course, everything CANNOT be covered by developer tests).

This software development practice of frequently running tests, integrating builds, often multiple times a day is called Continuous Integration.


CONCLUSION

I agree, at first, there seems to be a lot of effort in this but when you start practicing this, you will agree with me. You can push fixes till the last moment before the release because you know since your tests pass you are good to go. I bet it will work 90% of the time.

Like I said, everyone has a different opinion. I just shared mine and hope this gave you a little push towards trying TDD.