Haven’t really had a first-hand experience of Test Driven Development, though have come across some real promoters of it.

The two most common push back that I hear from developers or their managers for not being able to implement this are:

1 – It takes a while to implement as in training developers and them into the habit.
2 – The extra cost that is involved in creating those Tests

Image Source

I’d say both these factors are quite subjective and it’d be difficult to estimate the cost for them.

But Miško Hevery, an Agile coach and developer at Google has gone ahead and tried to estimate the Cost of Testing. And he has estimated an overhead of 10% for writing tests for any piece of code.

So a naive answer is that writing test carries a 10% tax. But, we pay taxes in order to get something in return. Here is what I get for 10% which pays me back:

* When I implement a feature I don’t have to start up the whole application and click several pages until I get to page to verify that a feature works. In this case it means that I don’t have to refreshing the browser, waiting for it to load a dataset and then typing some test data and manually asserting that I got what I expected. This is immediate payback in time saved!
* Regression is almost nil. Whenever you are adding new feature you are running the risk of breaking something other then what you are working on immediately (since you are not working on it you are not actively testing it). At least once a day I have a what the @#$% moment when a change suddenly breaks a test at the opposite end of the codebase which I did not expect, and I count my lucky stars. This is worth a lot of time spent when you discover that a feature you thought was working no longer is, and by this time you have forgotten how the feature is implemented.
* Cognitive load is greatly reduced since I don’t have to keep all of the assumptions about the software in my head, this makes it really easy to switch tasks or to come back to a task after a meeting, good night sleep or a weekend.
* I can refactor the code at will, keeping it from becoming stagnant, and hard to understand. This is a huge problem on large projects, where the code works, but it is really ugly and everyone is afraid to touch it. This is worth money tomorrow to keep you going.

Sounds promising! I am quite keen to discuss this with my development manager – what are their plans on this?