Alexey Varlamov wrote: > 2006/7/7, Tim Ellison <[EMAIL PROTECTED]>: >> Alexey Varlamov wrote: >> > I know the topic of test layouts is too popular here, but let me offer >> > some more grounds :) >> > >> > I think classlib tests should include a suite for VM-independent >> > kernel tests, like recently created testcases in H-765 and H-721. The >> > latter has gone to drlvm/vm/tests/smoke suite, which also has a number >> > of good candidates for moving to a common place. >> > >> > I see classlib/luni-kernel as the most natural location for now, but >> > maybe it worths a separate module altogether? >> >> If they are Java API tests then pop them into LUNI. The Kernel >> distinction is only for the physical separation of VM-specific types, >> they are still logically part of LUNI. > > Well, my perception was that we strive for keeping (unit) tests within > the same module with tested entities, that's why I suggested > luni-kernel. But indeed, the distinction here is subtle - consider > InternString test, for example...
The kernel modules, luni-kernel and security-kernel, are fragments of the LUNI and SECURITY modules respectively. They are simply broken out for packaging so they can be replaced by particular VMs, but at runtime but they are logically the same thing. > So for now it seems that we agreed to put such tests to classlib, > whatever module is appropriate in common sense. > > In the long-term outlook, I corroborate Geir's wishes for the > (sub)component for integration tests. The classlib doesn't have any tests that pass without a VM present, so they are all integration tests to a first approximation. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
