Before start writing code, think and ask yourself, why you are writing this code ? If you get your answer write your expectations as tests or if you don’t get why you are going to write code simply don’t write it.

Once you have documented your requirement as test, now let’s check what is the minimum amount of code you will need to write to complete the expectations. And once you have done that try running your tests and see if your code can fill up your expectation. If yes “Hurryyy” else no issues try to fix your code and run the tests again.

By doing this process again and again your will write code only for your expectations and the other part that is more important is before implementing any code you already know what to implement because you have documented it in your tests.

The process of developing by this kind of approach will take you far with less bugs and less time on rework.

TDD forces one to not write extra code that in unnecessary and later can be a reason for production bugs. Every time you write something you have chances of getting bugs there. And if you don’t have expectations and you don’t know what to implement clearly you are in trouble already.

TDD makes you document your requirements clearly that you can later use while developing the requirement.

By doing TDD you will end up writing more unit tests that will make sure you’re having less functional bugs.

:) Thanks for reading !

Application Developer at ThoughtWorks

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store