Test Driven Development turns automated testing up a notch; no code is added without first writing an automated test.
To drive code with tests, a developer starts by writing a test for the code he wants to write. He runs the test to check that if it really does fail. Now He writes the minimum code to make the test pass. After each new test passes, he looks for opportunities to consolidate the code and eliminate duplication. He builds up the code by repeating these steps.
Developing code this way encourages a developer to think about solving one small problem at a time. It also helps the developer work from the outside in rather than inside out, because for each test they consider the interface of the code before its internal logic, because applying TDD drives the developer to make small design decisions as they go, it’s also sometimes referred to as test-driven design.
Story Time: In my graduation days, I used to adopt Developer First and Test Last approach. That is, I used to refer multiple author books to gain expertize on any new concept. Only on the examination day, I used to refer sample questions just to be conversant on how the questions will be framed. Literally, I used to spend maximum of 2 hours’ time to refer the sample questions. Clearly, I was very stringent on my Develop First and Test Last Approach to the extent that everybody needs to be clear on the concepts first. Contrary to my approach, my friend used to adopt Test First and then Develop Just Sufficient preparation approach. After our professor teaches the lesson, my friend used to refer the sample question suite first and then he used to develop the just sufficient concepts. At the end, using my approach, I used to score around 80% marks with lots of preparation time where as my friend used to achieve 90% marks with less preparation. Though, during those days, I used to be very stringent on Test Last approach, but if I look back now.. I prefer I would have followed Test First approach.
I see a parlance of this story to our traditional development practices on the ground. I see teams resort to Develop First and Test last approach leaving very less time for Testing. With this “Inside-out” approach, we often see our product not meeting customer needs. Also, we see maintenance cost of our developed code is quite high as we keep on applying patches and enhancements to meet set customer requirements
