My hovercraft is full of eels

a truer word was never spoke. no, wait, it probably was. but i definitely agree with this.

Good blog entry, but I have a few comments. First, in my blog entry you cited I'm not trying to rant against unit tests. What I'm criticizing is an obsession with unit tests almost to the exclusion of other testing types, and the belief that the lower-level your tests are the better. Eckel's idea about embedding tests as comments in main-line code show that he's gotten to the point that the tail is wagging the dog, and he's forgotten the point of software development.

Secondly - alot of your article is comparing testing/QA in the manufacturing field vs. software testing, and I believe this is largely a mistake. Hardware testing needs to be done potentially millions of times over and over again - once for each thing rolling off the line. Software isn't like that - once the code's created you don't have to "manufacture" millions of copies of it :-). And hardware or physical goods are relatively static beasts compared to software. Software moves fast and isn't "manufactured", and hence its testing necessarily has to take these points into account. It sounds like your system has struck a nice balance, congrats. My blog entry was all about people who have skewed the balance towards low-level unit tests to the exclusion of almost all things - a rather different environment/design than what you described.

Hey Mike. Thanks for commenting. Really appreciate it. I was going to reply to your entry but my rant wasn't specifically about what you had to write it just made me think about it.

I guess I was trying to say that it's not necessarily a bad thing but, as the quote at the start hopefully suggested, obsession is not always such a good thing either and that, IMHO, ignorance and in-experience are largely to blame.

I agree in part about the manufacturing comparison too however, to me, the "manufacturing" process is really the compilation and deployment, not the copying. In an agile environment such as ours, that level of automated QA is paramount. I also dislike the comparisons made with the building and construction industry as a close relative is "real" architect and their industry is as "bad" as ours :-).

And as for Bruce Eckel's stuff, I'm in agreement 100%. It's one of the most crack-headed ideas I've seen in quite some time and, unfortunately, gives the TDD crowd a bad name for all the wrong reasons.

In the end, there is no substitute for good design and experience no matter how that may come about.

Cheers,

Simon

You sort of hit on what really motivated the article. A number of what are increasingly being called "Thought Leaders" are taking several good ideas and beating them so much to death that they're weakening the fundamental underlying arguments - and throwing people's views of software development, particularly people just learning, seriously out of whack.

I mean, it's kind of hard to argue against Unit Testing - as part of an overall development and testing strategy such as you outline. But Eckel, and others, are blowing things like Unit Testing _way_ out of proportion and are quite literally showing us how not to create software, at least given their examples of how to use these techniques. For example, Eckel never comes out and says as much, but the message if you read all of his stuff is "functional & integration testing are stupid and a waste of time - focus on Unit testing". As I said - he doesn't say it, but it's all he talks about, and if you look at his code and others there's almost no hint of any higher level tests.

The end result will be yet another backlash in a year or two - people rebelling against unit testing because they'll look at Eckel-inspired projects with 50,000 lines of too-low-level unit tests against 5,000 lines of code and no other testing strategy in place, and some joker (maybe even Eckel -these guys work in cycles) writing a book denouncing the evils of unit tests. Just like how the OO books from the early 90's onward kept changing their tune to the latest rage.

I'd like to behead the guys that wrote the Core J2EE Patterns book or for that matter the entire pattern movement for all the evil it causes in developers who blindly apply them with little regard to the underlying motivation. That doesn't mean I don't like say the original GoF patterns or apply them on a daily basis. What I do say is that, unfortunately, very little innovation has occurred since that thinking - most "new" patterns are really compositions (no pun intended) of other patterns.

Everyone these days seems to do some kind software development. We continue to believe that S/D is some kind of communist utopia where everyone is equal and everyone has the "right" to create commercial software. To me that's equivalent to saying everyone has the right to own a gun.

So maybe the real issue you percieve is one of responsibility? Should we allow someone who is considered a "Thought Leader" to publicly push an idea or concept (no matter hpw crack-headed it seems) as far as they can just to see what's possible or should we stifle innovation by "protecting" developers from themselves (and others)?

Whatever the answer, unit-testing as a concept and as a practice is not to blame. Though, if it does prove to be a dangerous thing for the majority of developers, then the government may have to step in a legislate against its use :-)

The main problem I have with the manufacturing example is that the vendor of the chips in the hard drive intends them to be general purpose reusable chips.
There's a set of specifications that it needs to comply to, and they test for that.

Most of the stuff we write doesn't need that. It's intended to work in this project, and if it does that job then it does what I need it to do.

Maybe it doesn't work in isolation, but if it work in integration, then how is the client any worse off?

(It's rare that something could work in integration if it doesn't work in isolation, but it does happen)

True but isn't the idea of interfaces and contracts that a component will work as advertised? If class A depends on class B, you don't usually "write" the contract as B will work in this way if and only if called by A.

The idea is to manage complexity. If we can break the problem down into manageable chunks of responsibility, surely that makes building and understanding the system much easier. The trick, as Mike originally points out, is to work out what the appropriate level of granularity is.

Simon, yep. For my own work, my definition of "unit" is much higher level than what you commonly see advocated by Fowler, Feathers, et al. My "unit" is typically a component visible to an external user, with all of the machinery that goes on behind it coming along for the ride.

This sort of unit isn't concrete and fixed as it traditionally is - usually, it's a class and a bunch of methods that serve as your unit. For me, a unit is conceptual - something that conceptually can stand alone, or mostly stand-alone. This may be one class, or several classes, or an entire package or sub-system.

I also advocate layers of this sort of unit testing - so that at some point as you move upwards in abstraction you start blurring the line between a functional test and a unit test :-)

As a final note - unit testing is utterly worthless for at least 50% of my code, since I work heavily with multithreading and networking. So much of my own testing is functional, stress, and load testing to see that the code performs correctly under real life conditions.