Re: Library/VM tests

[Tim Wilkinson <tim@transvirtual.com>]

I guess I wasn't thinking of testing the basic operations of the VM -
but
when it comes down to it they should be tested too don't you think -
after
all they have to work correctly too right?

Perhaps the testsuite should be split into various sub-trees contains
test
designed to go after particular bits of the Java implementation - you
could
put array[-1] in the tests designed to check the VM in one area and
leave the
API tests in another.

For such things as serialization I'm not sure what the best structure
would
be - arguably you can serialize any class (even ones which don't
implement
Serializable have a behaviour that can be checked) - perhaps you just
put a
serializable check in each class test directory, or maybe you lump the
serialization together (I'd go for the first option).

Tim

Artur Biesiadowski wrote:

> 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



--
  Tim Wilkinson                         Tel:     +1 510 704 1660
  Transvirtual Technologies, Inc.,      Fax:     +1 510 704 1893
  Berkeley, CA, USA.                    Email:   tim@transvirtual.com