From mboxrd@z Thu Jan 1 00:00:00 1970 From: Artur Biesiadowski To: Tim Wilkinson Cc: mauve Subject: Re: Library/VM tests Date: Thu, 01 Apr 1999 00:00:00 -0000 Message-ID: <36DE6CCC.83CF838B@pg.gda.pl> References: <36DC7DA9.16A46D4F@transvirtual.com> X-SW-Source: 1999-q1/msg00018.html Message-ID: <19990401000000.CyWzsbjzmOa48rePtLUx0acfQPUQ8yjyQr31u9yZXPk@z> 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 array[-1] 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. Artur