I was reading about unit testing and I came across Wil‘s blog article: Unit testing is teh suck, which was dated back in 2005. That title looked like it was asking for a flame war (as it happened) and it sounded very interesting to me right after I recently discovered the value in Test Driven Development.
The article was great, with many valid point. One particular comment from Shalev probably sums up my view:
I feel as if a great light has finally dawned upon me. The dark hypocrisy’s of people yelling “Don’t Repeat Yourself!”, and then turning around and writing their application twice have finally given way to the light of a new way. The fact is that code that fully tests an application will always be bigger than the application code itself. This has always grated against the grain of my least-code-possible programmer soul. I thank you for finally validating what I others claimed a defect in my programming nature.
The least-code-possible programmer soul, huh? That’s my philosophy all along.
So what’s my take on unit testing now? To test or not to test? I would say, be flexible.
From another of Wil’s article (forgot which one), he said something along the lines of “When people first learned objective languages, they go and create a God class, which inherits like 40 subclasses each with probably a couple of lines of code difference” That’s right, that’s probably also the case for unit testing: when people first heard of unit tests, they became advocates. (For the case of unit test, perhaps more people run away than to become advocates, but you get the point)
Does that mean objective languages and OO are teh suck? No! It’s the master programmer’s decision as to when to use what tools and when to not use them. These kinds of experience, instead of things like which language 0wnz which language, are what separate generic programmers from the true masters.
Unit testing in general is a good idea, but it becomes an anti-pattern when one gets restricted by it: waste too much time writing tests other than writing actual code, obsessing over than 10% of code coverage which is just a number (as high-scores from video games) Similarly, I think completely ditching unit tests is a waste of such valuable tools.
In the end, there is no need for black-and-white thinking here, just do what feels right at the moment based on your experience.