• Home
  • Why start with Test Driven Development

Why start with Test Driven Development


If You are anything like me, the most difficult part of some process is the start. When I want to do something for the first time, I always have difficulties beginning, and because of that a lot of my side-projects I had never started doing. So the technique to fight against that is to start from bare minimum and build on that, step by step.

It’s the same with Test Driven Development. It’s this “buzz word” that all the best developers in world are advocating and using. So I must try it. But the problem is that I am a mostly web developer. So when someone asks me to do a website, I don’t really see the point to test something. It’s just simple CRUD. I’m just losing time on doing things twice, once for tests, once for the real working code. Right?


I maybe am losing time initially, but I am gaining time overall. I have my own formula of calculating possibility of having a bug in my code. It’s

100% - codeCoveragePercent = possibilityOfABugInCodePercent

It’s pretty arbitrary but i have found out that it’s usually correct, so I am sticking to it.

When I say that I am gaining time overall I mean that after I think project is finished, I don’t get calls from client complaining about the bugs. So that’s the first time saver. When I am done with project, if client doesn’t want a new feature i never hear from him about this project again.

Second time saver comes when client wants a new feature. Well I have worked for almost 8 years as a programmer, and I can’t really remember if I ever delivered new feature without screwing something up in old code. I am just like that. I don’t have patience ( or I am lazy ) to manually test everything each time i change something. I need to have that automated. I need to have safety net.

Third time saver is that your code is simply better. Why is this time saver and why is your code better?

As I said in the beginning, the start is the most difficult. So when I am starting a new project I don’t have structure of code in my head yet. This is where TDD get’s into play. By writing just enough code to pass the test, I am basically structuring my code through my test and in a process my code is simpler, divided into unites ( modules ) and putting it plain and simple, it’s just better.

Structuring my code through test is flipping whole philosophy of programming, because I am looking from client perspective. What the end result i want my code to produce? This way features will not just not have bugs, but will actually do exactly what your client wants. And there is your third time saver.

To wrap up, yes every start is hard, but if you try to do it with small step, see the benefits and build on that, it’s gonna get a lot easier.

About the Author

Follow me

30 year old software developer from Mostar, Bosnia and Herzegovina, currently living and working in Frankfurt am Main, Germany.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}