This is the mail archive of the
mailing list for the Mauve project.
Re: Library/VM tests
- To: Tim Wilkinson <firstname.lastname@example.org>
- Subject: Re: Library/VM tests
- From: Artur Biesiadowski <email@example.com>
- Date: Thu, 04 Mar 1999 12:21:48 +0100
- CC: mauve <firstname.lastname@example.org>
- References: <36DC7DA9.16A46D4F@transvirtual.com>
Tim Wilkinson wrote:
> I have (finally) been looking into integrating our modest testsuite into
> Mauve but have run up against a problem. So far as I understand things
> Mauve is designed to test *only* the library functionality. Given this
> what are we suppose to do about test which sit on the boundary -
> ClassLoaders spring to mind but there's also such things as
> Serialization, Reflection and bunch of other borderline stuff. None of
> this is VM specific of course but it relies on more heavy VM support
> than some tests (some stuff uses threads for example).
> So my question is - what's the policy on this?
I think that as long as you test API, not VM it is ok. I mean that you
should not test if
throws ArrayIndexOutOfBounds exception, but if Vector.elementAt(-1)
throws such exception (even if it uses the same mechanism). In other
words, you can suppose that VM is perfect - only core lib can be faulty.
So, my personal opinion is that things that you mentioned fir into
mauve. Example fo thing that will not fit is StackOverflowException or
OutOfMemoryException testing - they are stritlty VM test, as there is
really not much to test in actual classes, and have a side effect of
possibly crashing entire test suite. I think that such tests (together
with bytecode tests etc), should be done separately - out of mauve.