From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brian Jones To: Artur Biesiadowski Cc: Tim Wilkinson , mauve Subject: Re: Library/VM tests Date: Thu, 01 Apr 1999 00:00:00 -0000 Message-ID: References: <36DC7DA9.16A46D4F@transvirtual.com> <36DE6CCC.83CF838B@pg.gda.pl> X-SW-Source: 1999-q1/msg00019.html Message-ID: <19990401000000.aTbAMqph7qc1UG1oxuy5rqOfoLtFqCvjzbLvRakVcrU@z> Artur Biesiadowski writes: > 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? > > 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. My personal opinion is that such a testing facility is needed for all the free VMs including Kaffe, Japhar, etc. If you want to look at the Mauve project as containing a couple of modules, one for testing core libraries and the other for testing vms/jit, then I think that would work well. What, if anything, has to be done to the testing framework seems like a separate issue to me as well. Brian -- |-------------------------------| |Brian Jones | |cbj@gnu.org | | http://www.classpath.org/ |