Nowadays it is quite common for developers to write automated tests. Somewhat less common is running the tests very frequently — getting them to pass every 2 minutes or so. This way of working can seem slow at first: you need to get the code to a working state every couple of minutes. However, in many cases it can actually be faster. Indeed, there are times when it feels almost as if your IDE had developed a magical ability to highlight buggy code; here’s why.
First, you simply cannot write many lines of code in 2 minutes. So when a test fails, you don’t have a lot of code to check: the bug is probably in one of the 2 or 3 new lines you just wrote. (The rest of the code is probably fine because the tests worked before adding the new lines.) In contrast, if you had modified 50 lines of code before running the tests, you might need more debugging to determine which of the 50 lines is in error.
Additionally, odds are that the offending code is still fresh in your head: it is easy to remember what you did 1 minute ago. Indeed, sometimes when I’m lucky I don’t even need to look at the failure message to recognize the mistake.
Of course, there are always changes that work better in bigger chunks. Nevertheless, for beginners I would still recommend trying small chunks even when they feel slow. This is because it may take some time before the small chunks start to feel productive — perhaps a month or two. For some inspiration to get started, a good example is the bowling game kata by Robert C. Martin.
