Comments on: Testing patterns: don’t assert without cause

By: Tom Hawtin

Tom Hawtin — Tue, 31 May 2005 04:06:05 +0000

Seems to me like it’s a variant of always check for null argument idiom.

Both are a good idea, IMO. You want to say explicitly in the code that nulls are out. And as a side effect you don’t have the possibility of code changes removing the check in some obscure cases.

By: Michael

Michael — Mon, 30 May 2005 19:33:58 +0000

I found myself slipping into a pattern where I would stuff a whole lot of assertions into one method, whereas I *should* be doing what you suggest above (breaking out important assertions to indicate a major failure seperately from more functional tests).

This is cause I am going through a slow test suite-hatred phase. And that leaks down into me thinking “that doesn’t really need a test all of its own…”…

(of course the real reason for slow unit tests is cause they often aren’t unit tests).

By: Robert Watkins

Robert Watkins — Mon, 30 May 2005 13:04:50 +0000

It _can_ be sensible to put the assertNotNull() in. This, BTW, assumes that failures make more sense than null pointers.

The problem lies in the _repeated_ assertions. Assert it once, in one test, then don’t do it again.

Of course, the assertNotNull isn’t the only example of this particular anti-pattern; it’s merely the most prevalant.

By: Michael

Michael — Mon, 30 May 2005 12:24:17 +0000

Interesting. I too assumed that it was sensible to put the null check to stop the annoying null pointers.

But as David Brent says “assume puts an ass between ‘u’ and ‘me’”.

It is also an interesting point that if you look at your failures first, you will have a better chance of seeing at a glance what is wrong, rather then looking at the exceptions peppering your results.