There’s no time for Unit Testing

Jake looked at the clock. The whole day passed and he had only done a few tickets. Not that much code written anyway. Where did the time go? 

The “good old” way of coding & debugging

Well, a lot of time was spent with the Debugger. The features weren’t that complex, but the main problem was every time he ran the code with the debugger, there was always something missing, so it was just several back-and-forth between writing the code, running it – sometimes it felt like an endless loop. 

And then, just when everything finally worked, QA reported some bug. So then Jake had to make those fixes, but then something broke in the existing code so then he had to debug both the old code and the new code, several times, until it finally worked. This time he was really “hoping” that QA wouldn’t find yet another bug. But the problem wasn’t just the QA bugs, but also the client. After seeing the new feature, the client got some amazing new ideas which meant that Jake had to repeat the coding-debugging cycle yet again.

How about Unit Testing? No, there’s no time for it

Now, Jake did hear about unit testing, but there was simply no time for unit testing. The deadlines were tight, and after all, the client doesn’t want to pay for unit testing anyway. There were some others who had tried unit testing for a while, but said it was a waste of time. After all, unit testing is just something that’s in those clean code books, fancy conferences but it not useful in the real world. In the end, the “good old” debugger way was the only way…

But what about Manual Debugging? Here comes the surprise

Then one day, Jake started thinking about Unit Testing again and to do some sample calculations. Let’s say for some feature, it takes about 10 mins to implement one scenario. This is a simple feature and the testing is simple, it takes about 1 min to run the debugger and check the results, but it takes about 5 code-debug iterations of debugger by the time that the scenario implementation is done. On the other hand, writing a unit test might take 2 mins (which is longer than the 1 min required to run an iteration of a manual debugger test) but the benefit would be that subsequent runs of that unit test are about 0 mins.

And then he discovered that actually development takes LESS time with unit testing, even for some easy to test feature scenario.

And what happens with the not-so-simple features, where it takes longer to do even one iteration of the debugger testing (e.g. 5 mins instead of 1 min). The differences then start becoming even more drastic.

The Happy Ending – Faster Development & Higher Quality

The calculations above decided to be too good to be true, but in any case Jake decided to try it. At first, it did feel a bit awkward, especially now that he had to think about the test first, and avoiding the temptation to just jump into coding. But, after a few features, he really got the hang of it. Suddenly, feature development was so much faster, he didn’t have regression bugs, and implementing changes requested by the client became actually fun. People around him noticed the development speed, but no one knew the reason why. 

As he looked around himself, and as everyone else was still using the Debugger all day long, he decided to share his secret – unit testing. At first, everyone stood back and said “There’s no time for Unit Testing” and that’s when he told them about the story of his journey to Unit Testing. Soon afterwards, the whole team productivity went up, and that was just the beginning of the next chapter – a journey towards Clean Code.