isA function?

[Peter Hansen]

"Delaney, Timothy" wrote:
> 
> > From: Peter Hansen [mailto:peter at engcorp.com]
> >
> > For example, a unit test for a factory function might be checking
> > that instances of several different classes were being returned
> > depending on the parameters passed in.
> >
> > If the code were broken so that only a single class was represented
> > in the returned objects, Timothy's test would continue to pass
> > (bad!) while yours would fail - just as you'd want - alerting you
> > to the bug.
> 
> Why would this be bad? Presumably you are testing that the returned objects
> have specified semantics. What does it matter if the returned objects are
> all of the same type or not - what is important is what happens when you use
> them.
> 
> Assuming that the code was *broken*, this would show up in other tests.

I guess you can write unit tests your way, and I'll write them my way.
I want my unit tests to test the *unit*, the thing I'm trying to test,
so I can localize the failure immediately.  I don't want the test to
ignore certain possible failure modes so that I have to waste time 
debugging when some other test fails on a routine way across the
application, even though it's the factory method which failed.

> Artificially restricting the types that you can deal with is generally a bad
> idea. If it passes all the unit tests, either it is acceptable, or your unit
> tests are broken. If it passes all your unit tests except for an arbitrary
> type check, then I contend that your unit test is broken.

I contend that this advice is good for real code, but when writing unit
tests it's okay to break it.  At least, this is what I have found to
be a practical way to work when doing test-driven development, where
each unit test is written before the code that will make it work.  If
I want to extend my factory method to return another type of object,
I must write a unit test which will fail if it does not do so. 
Limiting myself to a single test which checks that all returned objects
have the right signature is inadequate in this circumstance, though
it may be acceptable for you when doing traditional unit testing,
writing tests after the fact.

-Peter