He devoted the first several minutes of his talk to why unit testing sucks. And oddly enough, by the time he was done I was a convert.
I asked him if he had a blog post on that I could share, and he pointed me to this one:
Unit testing is teh suck, Urr.
http://blog.wilshipley.com/2005/09/unit ... k-urr.html
A worthy read, IMO, whether you agree with it or not, well worth the few minutes, though this snippet gets to the core of his point:
Having been immersed the last few weeks in a code base in which most components had good through significant unit testing but are exhibiting issues with their interactions, I can sympathize with Mr. Shipley's plea for more holistic testing practices.Most programmers don't know how to test their own stuff, and so when they approach testing they approach it using their programming minds: "Oh, if I just write a program to do the testing for me, it'll save me tons of time and effort."
There's only three major flaws with this: (1) Essentially, to write a program that fully tests your program, you need to encapsulate all of your functionality in the test program, which means you're writing ALL THE CODE you wrote for the original program plus some more test stuff, (2) YOUR PROGRAM IS NOT GOING TO BE USED BY OTHER PROGRAMS, it's going to be used by people, and (3) It's actually provably impossible to test your program with every conceivable type of input programmatically, but if you test by hand you can change the input in ways that you, the programmer, know might be prone to error.
Your thoughts?