I think allowing tests to be fully executable in Java (i.e. a certified jvm) would be really tricky. Some black-magic to rename all classes would be required, and testing some core functionality would be really hard - think synchronization and threading.
But for most classes this is perfectly doable. Just rename everything but some core classes (Object, String and a few more final ones) to be in the test.* package. For example, java.util.ArrayList would be test.java.util.ArrayList. I think this could work, most of the times, and allow testing harmony classlib inside a jvm. But then, the real advantage of doing this would be if we could compare the results between a certified jvm and harmony and sport mismatched results. I just can't see many bugs been caught by this approach only. Rodrigo On 1/16/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > One thing that's popped up on the "Test suite layout" thread is the > thought that we need to b0rk the canonical package and naming > conventions for unit tests in order to be able to run things on the boot > classpath of the VM. I think this issue is important enough and > fundamental enough to warrant it's own thread. > > First, do we really need to do this? I thought that we (Tim and I) had > informally discussed this at ApacheCon and came to some good conclusion > where we were able to figure out a trick. > > Second, shouldn't we think about providing a test environment in which > we can completely control the environment - we can test the class > library in a container that can be run in any VM so we have full control > over security and other issues? > > Of course, I'd like both. If we do have the "trick" that we talked > about, then we can use canonical JUnit (or TestNG) naming and package > conventions, which I think is important. > > geir > >
