Before the lockdown, I have attended a lot fo technology conferences and everyone was talking about TDD. At that time, I was completely clueless. But now, I am happy to say that I appreciate it a bit more than before.
A bit of background history of how I've got addicted to TDD, it was because friend of mine suggested I should look into Exercism if I ever wanted to challenge myself. It is an open source coding platform that allows you to practice your programming concepts with free mentorship. One major plus is they have already written the tests for you. So your only job is to pass them. Until now, I get a lot of adrenaline completing them when I am free. To further challenge myself, I would write my own tests, fail it, write some code to pass the test obsessively and then refactor.
Professionally, I am quite fortunate to work in a company that focuses on software quality and I have a lot of chance to practice deliberately on what I was not familiar.
In my current team Zephorus, we have a lot of tax calculations, all the calculated fields are made up of other sub-components. These sub-components are also dependent on other fields, and some of the fields are sourced from another tax return. The "dependency hell" was really difficult to lock down the calculations we wanted to test.
That's when I started to appreciate the power of unit testing. By using a divide and conquer approach, we can find problems/ edge cases early on so that we don't trip ourselves in the future. I remember the first time when I wrote my first unit test, it was definitely a paradigm shift in how I view software development process.
It taught me that it is okay to start small and the importance of doing this one thing, passing this one test at a time. Yes we are expected to fail out first test and that's okay too. While it's good to have a big picture of what your problem you are trying to solve, but we don't need to take on all the complexity of all the components early on.
If you don’t have validation for the problem you’re solving, you’re at a disadvantage because the implementation you thought of in your mind may not be something the requirements want at all.
That's beauty of it! Now you can write the simplest code to pass the failed test. If you fail, just change your code until they pass. Finally, congrats! You passed all your tests! To make your code even better, you might want to refactor it and make it more readable and maintainable. And run the test again, rinse and repeat.
In short, TDD still requires a lot of discipline and efforts to maintain. Yet, you can reap the rewards as it provides a positive feedback loop to validate your success and can save a lot of time in the long run.
At the end of the day, if you are a software engineer, or thinking to become one, I leave you with this quote from James Grenning: "If you’re not doing test-driven development, you’re doing debug-later development."
Don't be afraid to be wrong,
Kevin
Top comments (0)