I recently came across this blog post on automated unit testing. This time I was really curious about the opinions on the topic. And quite not surprisingly it turns out there are two groups of people with two totally distinct attitudes to unit testing. There are the lovers and the haters.
What struck me, though, is that neither of them pointed the real value that is brought by a set of unit tests to a piece of software. As the examples given by the author are written in Python (which is not a statically typed language) somebody pointed out that the most of the issues would never happen if a statically typed language was used. And they were just a bit mistaken: you would run into the same problems, but you would detect them so early that you would never consider them as real issues.
And that’s what unit testing (or a fast set of automated tests) is made for. The main goal of unit testing is to provide a set of rules that are checked at compile-time (I’d call it ‘test-time’, still it should always be as close a possible to compile-time). A set of unit tests should play a role of a safety net that finds out all pieces of code that do not comply with the defined rules. And this should be done as soon as possible. Ideally, it should be as quick as the statically typed languages perform their type verifications.
And thanks to unit tests you can define any set of rules you like.