Unit testing is dumb
I just read Eric’s beautiful post on unit testing and it struck a chord (well several). He’s right on that testing “trivial” classes and code feels dumb…right up to the point where it saves your ass.
I am repeatedly (and humbly) amazed at how many tests I’ve written on code that was “too simple to fail” found bugs. This could be because I’m an awful programmer. I’m comforted by the thought that I’m not alone, though.
I actually did an internal junit / unit testing talk many years ago (before it was pervasive) and grabbed some “simple” untested stack class I’d written to test live during the talk. The very first test I wrote actually exposed a bug in the class that I was unaware of. It was so perfect, that I’m sure it looked staged.
I also like the quote: “People who never write tests do not grasp this concept.” There are a number of effects from testing that really need to be experienced to be understood. I’m not sure why, maybe because they deal with emotion. I guess you need to actually experience the difference between being afraid to change code because you’re sure you’re going to break something to feeling the freedom to refactor and fix problems because your tests tell you it’s ok. Or the difference between thinking code works and knowing it works with a mountain of evidence to back you up. Or the satisfaction of reproducing a customer problem in minutes by extending an existing test, fixing the problem, and verifying with the test, knowing it’s fixed forever.
Hi! My name is Alex Miller and I live in St. Louis. I write code for a living and currently work for 
How do you know that your Unit test code is functioning correctly, and is not missing bugs?
Obviously you don’t. There are of course an infinite number of ways to write better tests, just like there are an infinite number of ways to write better code. Some good ways are review (whether via code review or pair programming) or by manually breaking your code to see if your tests break as well. Or test-first of course.
In any case, I’ll guarantee the tests you write will catch >= more bugs than the ones you don’t write.
Here’s another good, old post on this topic: “It’s the Exceptions, Stupid!”
http://www.matshelander.com/Weblog/DisplayLogEntry.aspx?LogEntryID=25
His opinion is the value of unit tests is not in the green bar, but the red.
Unit tests can’t prove your code to be correct, but they can demonstrate when you’ve broken something. (Of course, refactoring is based on the premise that you’re comfortable enough with your unit tests to allow them to guide you in making changes while the bar remains green. It’s not foolproof, but it’s better than having no unit tests and just hoping for the best.)
I very much appreciate the Ted Neward post you linked to. I like the idea of a culture where software developer peers can admit to each other “I write terrible code – I ultimately write good code because I understand this and do something about it.” I love that Kent Beck was famously quoted as saying “I’m not a great programmer; I’m a good programmer with great habits.” This is the sort of culture I want to work in.
I love that test driven development takes the pressure off me getting something exactly right the first time, since I never would anyway.
Good ideas.. at the same time don’t get lost thinking your testing is done just because you’ve written some unit tests. Unit testing reminds me of checking that every word is right spelled while verifying not grammar correct.
Yes, I’ve blogged about this before as well in Weaving the Test Fabric.
In other words, to misappropriate Linus’s Law:
“given enough code, all tests are shallow”. :)
One way to test your unit tests is to “sabotage” your code, and make sure that this makes your tests fail. heckle in ruby looks like an interesting way to automate the sabotage process :)
I can’t believe we are still arguing that tests are necessary – this must be fear based, fear of what? Fear of being found out (transparency), fear of change.