Re: JavaDocs vs. Tests (was: Interview)
In article <alpine.DEB.1.10.0910062052300.11636@urchin.earth.li>,
Tom Anderson <twic@urchin.earth.li> wrote:
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:
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!
Testing for implementation defined behavior is no picnic either.
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.
It might be a problem. If the spec (and implementation) changes then
ideally some of the tests will start failing and then it will be obvious
that they have to be fixed. This test won't fail - you'll just have to
remember to fix it. I'll remember. You will too. However, some of
your coworkers are (how can I put this?) a little "flakey". They might
forget. Then you have a unit test that passes for the wrong reasons.
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.
Sounds like the perfect application for a quantum computer.
Alan
--
Defendit numerus