Yes, I write unit tests because I don’t want to test manually. I prefer to write code which can be tested directly, instead of having to fire up the UI and push all of those buttons. This also makes the code more OO and easier to understand. This is not just my opinion or dogma. My peers have confirmed this.

Most of the bugs, trivial or serious, I’ve encountered are “stupid” coding mistakes. They could have been found if the author (including me) had take the time to write unit tests up front.

The really “incideous” bugs usually pop up from some nasty piece of code that I call “stream of consciousness” functions. You sit down, you have everything in your head the code needs to do and you just start coding. It made sense at the time, but once that thought slips from your brain, you have no idea what the code does.

This kind of code usually doesn’t have unit tests because the developer just blasted it out non-stop. And every time someone new looks at it, they decide that it will take 2 days to understand the code and write unit tests, or just 2 hours to kinda understand the code and make a change that you THINK won’t break any thing.

And yes, most of my points are not absolutes. It is possible to write a unit test for code that is not OO. And one can write OO code without writing unit tests. It is also possible to write unit tests for a transaction script that is 700 lines of code. And I suppose it is possible to write a huge transaction script which clear and elegant, but I’ve never seen it.

“Be careful when opposing testing. Nothing has ever been proven without being tested for correctness.”

It is fun to see intelligent words of someone in opposition. Unfortunately, I view these words as coming from someone who has wasted time creating worthless unit tests (such as getter/setter testing) and has never had the opportunity to be mentored in creating great unit tests.

Either that or the most intelligent flamebait I have ever seen…