Just Another Reason to do TDD

28 Nov 2014, by Moe in Developer

Typically Test Driven Development is done in order to increase the quality of the product and help keep the code maintainable. I feel the need to point out something that I don’t see enough of which is TDD helping the developer break down the problem into smaller chunks and working on a little bit of functionality at a time.

We start with a bunch of features and rules that need to be added. Rather than trying to think them all through and imagine what we need to code and waste a bunch of time trying to code something complex while keeping our heads wrapped around it, we can break it down. Our next step is to start writing a test to make the first case of some functionality pass. I can then move onto the next case and so on and so forth. I don’t actually have to spend time thinking about some functionality, as long as my tests continue to pass as I program the business rules I’m good. Once it’s all said and done I can refactor, check my tests and so on.

You might say, “I don’t have a problem understanding all the logic I need to implement”, and that’s great but there will always be a problem that’s just too complex to keep in your head while trying to program for all the cases and scenarios as well. Even if you are superhuman and have the mental capacity to go through and fully understand the problem you still wasted some time understanding it, time that could be spent writing a test and code. An example would be relationships in a donation system. We need to account for several types of relationships (friends, spouses, employment, etc.) and each with their own set of unique business rules and cases that have an effect on the data for the people in that relationship. Rather than trying to go through all possible scenarios and trying to create something that can handle something that could nearly be considered an engine, we can keep it simple. Pick a scenario, and start writing a test and then make it pass, then move onto the next scenario. I don’t waste time and I’m writing tests to help keep the code maintainable!

In conclusion, by utilizing TDD one can start programming a feature without even really having to understand it completely. Allowing the developer to focus on the interface before implementation and tackle the problem by using test cases rather than assertions and preconceptions.