Re: JavaDocs vs. Tests (was: Interview)
On Mon, 5 Oct 2009, Alan Morgan wrote:
In article <alpine.DEB.1.10.0910041931480.21268@urchin.earth.li>,
Tom Anderson <twic@urchin.earth.li> wrote:
On Sun, 4 Oct 2009, Alan Morgan wrote:
In article <alpine.DEB.1.10.0910041355520.21268@urchin.earth.li>,
Tom Anderson <twic@urchin.earth.li> wrote:
On Sun, 4 Oct 2009, Kenneth P. Turvey wrote:
On Sun, 04 Oct 2009 12:03:43 +0200, Ed Kirwan wrote:
How many units tests would be necessary to test that method? Maybe 2? 3?
How would a developer get more useful information from these 2 or 3 unit
tests than from the description above?
Certainly it would be a few.
I'd want to test, and really ought to write a separate test method for,
each of:
One test that you can't do is adding a collection to itself (or adding a
collection that changes to another collection) and verifying that the
results of that operation are undefined.
Correct. I'm not sure how i'd test that it did something undefined -
perhaps have a list of defined things it might mistakenly do, and check
that it doesn't do any of those?
That sounds like the "undefined means sorta defined" approach. Not
buying it, but nice try.
We can define it as not being defined!
Oh hang on no, wait ... we ... OH GOD
I started that post thinking that i'd have to write a test with a
collection that gets modified during addition (which would mean hooking
into the added collection's iterator - ick), but then i realised that
because that situation is only mentioned to say that the results are
undefined, there's nothing to test.
Now that I think about it, you could do something like:
try
{
dontAddACollectionToItself.addAll(dontAddACollectionToItself);
}
catch(Throwable t)
{
// Throw whatever you like, I don't care!!!!!!
}
assertTrue(true);
The problem with this is when the Java spec is changed to require that
this throw a RussellsParadoxException your test will continue to pass
even though it shouldn't.
Firstly, changes to the spec do mean changes to the tests. That's not a
problem.
Secondly, that exception would only be triggered by:
Collection<Collection> allCollectionsWhichAreNotMembersOfThemselves = new Collection<Collection>();
for (Collection c: Collections.universeOfDiscourse()) {
if (!c.contains(c)) allCollectionsWhichAreNotMembersOfThemselves.add(c);
}
Current proposals are that the exception would be thrown on exiting the
for loop.
tom
--
22% Essential Components, 22% Repetitive Patterns, 56% Pauses