Why it is worth adding tests even when the investment is large

Have you ever found yourself fixing a bug or adding a simple feature to some code that have no tests and since you usually do things test driven you know you should get the code under test but you decide not to because the change only takes a few minutes and getting the code under proper tests would take days? The first time it might feel OK but then you find yourself having to touch that code again later and sooner or later you end up regretting you didn’t get the code under test the first time.

I’ve been in that situation and each time I make the same mistake since the trade off feels reasonable. But in hindsight almost all the time it would have been better getting the code under test right away. And a few days I found somebody who actually took the time to get some numbers proving why you should get the code under test as fast as possible. The interesting fact is that in two large projects (gcc and python) the probability of touching the same code twice in the same week is 35%. The number might be a little on the high side since touching the same file twice in the same week does not necessary mean you’re working on two different things. It might be incremental check-ins. But if they’re incremental, then it’s probably worth getting the code under test anyway since you’re spending days on the code anyway. It is also interesting to see that there is almost a 50% chance of touching the same code twice in a month.

So now we have great statistics and a gut feeling telling us to add tests the first time even if it feels costly at the moment because the probability of the investment to pay off within a few weeks is very high. And you’ll be much happier the second time around this way…