Unit Testing ++

(Yes, I need to follow up on tech debt. Still ...)

Not to many years ago, Brian Marick pointed out that you can tell when a product has "crossed the chasm" into main stream when the first non-introductory books start coming out.

That was 2005, and he was talking about Test Driven Development.

I just found "The Art of Unit Testing", a book by Roy Osherove to be released in November 2008. The first chapter is available on-line.

This is going to be a good book, and I am super-excited about it.

Sidebar: For years, I've been saying that the developer-test community has a great deal to learn from the traditional test community. I've blogged and published about. it.

The book introduces unit testing with different definitions, starting with this definition for "classic unit test":

A unit test is a piece of a code (usually a method) that invokes another piece of code and checks the correctness of some assumptions afterward. If the assumptions turn out to be wrong, the unit test has failed. A “unit” is a method or function.

This is introduced with no references. No Glenford Myers, no Boris Beizer, no Bill Hetzel. Just a statement above about how Kent Beck invented unit tests in smalltalk and popularized it for other languages.

Let me be clear: I think this is a cool idea. I think it'll be a good book. AND I think the (clueful) traditional test community has a ton of lessons learned that we can share with developer/testers.

Does it all apply? Well, no. Some of it will. Again, let's not throw the baby out with the bathwater.