Testing is hard. But why?
As developers we like to think of ideas and translate them into code. This process of turning thought into reality is a very empowering experience and forms a strong positive feedback loop that helps us become faster, more concise, stylish, and even more elegant in how we write our code.
The problem with testing, or writing tests, is that it forces us to imagine all the ways current or future versions of our code may be wrong. The more exhaustive we want our test suite to be — the more we have to challenge ourselves and explicitly state all assumptions made in our code. The experience feels like creating and then facing all your worst nightmares.
Without a good amount of masochism in your DNA, this doesn't come naturally to you.
In the best case, at the end of having spent twice the time it took us to write the code being tested, all we have to show is that our code meets expectations. In terms of grading, passing all your tests amounts to a “satisfactory”. There is is no way to get an “outstanding” or “excellent” in the testing game. In most cases though, we find that we screwed up somewhere — so the test really pays for itself when it tells us that we are wrong!
The emotional cost of thinking like a paranoid and the lack of reward make this entire exercise a negative feedback loop. We then want to outsource this thankless burden to anyone willing to take it from us. We thus end up creating armies of manual QAs and Test Engineers responsible for verifying that our implementation conforms to the product specification. In someways, this is like relying on a third party auditor to do our accounting, but hey, as long as the auditor doesn't complain or charge too much, we are happy.
At this point, if you are thinking of Test Driven Development, you should ask yourself why you have never actually used it despite having heard of it so many times and perhaps even pretending in an interview that TDD was your style.
Again, the positive feedback loop of translating thought to reality is very addictive and you will have and easier time quitting cocaine than changing your coding style (ok, maybe not, but you get the point).
A more pragmatic approach to dealing with Testing is to invest in tools that reduce or eliminate this burden away. Writing tools is extremely rewarding because tools are products themselves. We end up leveraging the positive feedback loop to create elegant solutions that do no rely on others doing this work for us. They give us the feedback we need without making us spend hours. Most of all, these tools we build are generic enough to work across projects so the investment cost is better amortized than any project-specific testing effort.
A small caveat to the beautiful Tools story is that tools themselves also need to be tested — but that's for another post.