Have you ever been in a situation where a hot-fix was breaking the software even further that you had to roll back that change? I have, and it wasn’t a pleasant experience at all. We rolled out the feature, and it was essentially breaking the entire login process on the mobile for OAuth users. We rolled back our changes which involved multiple people such as ops, devs, QAs, PMs, etc. Could there be a way to prevent these show-stopping bugs to production? Turns out there is!
Simple answer is, Everyone in the team can build habits of testing, rigorously.
Test Driven Development is one of the processes that can get you in the habit.
Test Driven Development (TDD) in a nutshell suggests the tests to be the driver of producing the software. You continuously run through these tests to complete your algorithm and progress based on the feedback from the run. We usually write algorithm first and then write tests required for the algorithm. We reverse this process to complete your algorithm. Once all the tests pass, one can further refactor the algorithm to complete your code.
When Kent Back first developed TDD, he sought to narrow the gap between the algorithm decision and its feedback. TDD is the psychological process for closing this gap. When you have enough passes and fails during your tests, you are getting consistent feedback on the decision you made. That’s where you become confident with the changes you have made.
TDD has a fundamental guideline for anyone starting their programming.
The importance here is that you wrote tests to fail and fixed them along with refactoring.
Another important concept here is that you start with test cases that fail. And then begin developing your algorithms. And repeat this process in a short amount of time.
If your project has steadily built where the result is quite apparent (we all know 1+1 is 2), TDD is probably an overkill. TDD is useful when there are uncertainties in your software. If your software is pretty simple, don’t over complicate things. However, with increasing number of users these days, we have variety of microservices and software is quite complicated. We can easily encounter frequent changes which may involve different microservices and often time we lose the confidence in making such changes.
One important benefit from TDD is that the programmer would understand well what the expected outcome when developing the functionalities. TDD helps you precisely to overcome that uncertainty. Also following TDD avoids writing redundant code.
There are so many pros and cons of TDD. From my experience, the pros win over. I have acquired the habit of writing tests for anything I write, which is how I gain confidence in my code.