Unit testing has been around for ages (or at least since 1986, when IEEE standard on unit testing was confirmed). It still surprises me, though, how many people just won’t do unit testing. Reasons they state differ, but most of the times I hear something along the lines of: “Unit testing is too time consuming and when you are in a hurry, you don’t have time to fool around with it.”
Now, I am no unit testing evangelist (and many of my past co-workers can vouch for that), but this is wrong on so many levels, I don’t even know where to start. Let me tell you a little story.
When I first started with Unit testing (way back in 2011), I was of the same opinion as well. Then, a project came where I had to write software for storing information we obtained remotely from a stock broker company. This program had to connect to company’s API and of course, no testing environment could be established. Also, the PC used to connect to the company was constantly occupied. Thus, my only option to actually test, if my software is working was to go four flights of stairs up with my laptop, copy the software to the PC at hand and then run the software and see if it works. Much like in the days of mainframes and punch cards. That was the first time, when I thought: “Hmm… maybe if I can somehow test the logic my program uses and be confident that it works, I will only have to deal with one crisis and that is not knowing how exactly API works.”
Hence, I started to teach myself in ways of unit testing. Now, not being a very skilled unit tester at that point, I did tons of things, one should never ever do. Like, writing data in the database and then delete it later on or sending an e-mail to mail address. Still, when I was done (and way before deadline as well), I was pretty confident that my code will work and now just had to test it on that forsaken PC. It took another hour of fiddling with API implementation at the PC location and ever since then the program runs 24-7. Without a glitch. And ever since then, I consider unit testing as essential part of my projects.
You see, the thing with unit testing is, that the time you spend writing test code would be the time you would otherwise spend on testing and fixing bad code. Not to mention the time you would spend retesting and fixing bad code when new features arrive. With unit tests, you are always sure that as long as test passes, everything works as it did. It may be that you will write more code, but you will write it quicker and better than you would without tests.