How TDD improves development speed and is very cost effective

When it comes to automated tests the first impression everyone (including myself) thinks that that would certainly increase the amount of time a certain feature is developed in. However as I started to practice TDD, Test First Programming, increasing the number of tests I came to the conclusion that automated tests actually allow you and the team to develop faster then without.

Move faster ahead in development

A simple comparison of programming vs walking on a rope. When walking on a rope, at a height, with no safety net, walking is much harder , much slower, as the risk is higher. Only very experienced people can walk fast. When having the safety net below, the rist of falling suddenly doesn’t really concern you that much. If you fall, you just go back and try again. You do not jeopardize your life.

With programming, the bigger the code base gets, the hardest is to move further, to change all code, being very afraid, that you could mess it up really good. If you have automated tests, they are your safety net, allowing you to see if one mistake you did affects the system, and you have to roll it back just like falling off the rope makes you go back to the start. A little time is lost, but not the system, you do not need weeks to restore it. The fact that you can see the mistakes you do very fast, makes you a lot braver, having the courage to change a lot, adapt, improve, refactor a lot, then when you don't know what you're doing. The safety net, composed of tests gives you that very fast feedback that something is broken. These tests are also called change detectors. When you do a change, the tests will detect very soon if it breaks something.

Faster development by automating the process

In a recent project, we had a business process on a web application that required the user to go, like in a wizard, trough 9 screens to be able to ship an order. When we were developing it, we had to go 9 pages, filling 9 pages of data to see if the order can or cannot be shipped. We had a lot of times, the order being rejected by reasons that we forgot to fill in some field. This process of filling in all the fields until screen 9 took usually 2-3 minutes, so after 2-3 minutes to see an Exception is not really nice because it just means you have to take another 2-3 minutes to refill and hope this time it will be ok. After a few attempts, I realized this was not the way to go I said what about we automate the whole filling process, , and being a web application we used Selenium (http://selenium.thoughtworks.com) a great functional testing tool for web applications, which did the whole 2-3 minutes manual process in under 4 seconds. Now instead of starting the first page, we ran the test each time until we got the process of shipping right, with all the validations. It took 15 minutes to write the test but it probably spared us of a lot more manual testing. And when it worked, it could be retested whenever we felt like it, in 6 seconds. It was added to the test suite and we made sure that it always succeeded, so we knew all the time that even with our 'big new changes' it still worked.

Minimizing debugging time and cost

Usually people have the tendency to think that by adding automated tests the development time increases. They say that if you have something to implement in 4 hours and doing the tests would take 2 hours, you have just lost 2 hour writing the tests. Coming back with our feet on the ground we can soon realize, that that thinking is superficial as it presumes that the code done in the 4 hours of development is bug free. That is bug free and will stay like that even if the system around it changes, gets bigger etc. The sad truth is that most code is not bug free for the first time, and a lot of time is lost debugging it. In many cases the time to debug is bigger then the time it was developed in and this time usually increases as the time goes. The biggest problem is maybe that usually debugging time is not measurable or it is hard to predict how much time it will take. So 4h+??? = ???

If the bug is discovered by the client, solving it is usually not paid, so it's cost just doubles or grows even more. Many times you end up with a negative balance when saying 4h developing=10$ then fixing the bug 4h=10$. The company ends up with 10-10=0$. And this is a good case.

Automated tests, with a good coverage of possibilities, will reduce even eliminate the debug time and if they are kept in a test suite that is run very frequently will make sure they remain bug free. In this case you use 6h, but you're very sure you've done it right.

Automated tests help you get things right the first time, costing less

A similar sample was with my wife. She went to buy paint for our doors. She bought two cans, one with 0.85 the other with 1.55. When we started painting we quickly realized that the 0.85 paint , needed to be put twice on each door, so is actually costed double: 1.7. Now if she bought two cans of 1.55 we would have paid less money and less effort. The very same goes with automated tests. They seem to cost more then developing without them but they usually end up costing less, as you get the things right the first time and not after the deployment, when you fix the bugs from your own pocket.

I hope the 3 reasons above gave you an idea, why I think developing being backed up by automated tests actually help you develop faster, then developing without them .