Just a random idea... Why not have a special "testing" mode in the VM that would trigger special permissions to code in ".test" packages?
Actually, this mechanism could act differently: simply consider some.package and some.package.test as being the *same* package (so, erase, at loading time, the .test package suffix from loaded classes. It could also "combine" the fields & methods of package.Foo with package.test.Foo if classes with identical names exist in both packages, so that private methods could be tested. Additionally, the testing mode could allow for loading java.lang.* classes in user class loaders. Of course, this would be a non-standard option, like -Xtestpermissions . And, this way, all the test code could reside in files and directories that would be separate from the real code. Yep, a random idea. ;-) Etienne Geir Magnusson Jr wrote: > testing a.b.c.Foo and you have to do it from a.b.c.test.FooTest, how can > you ever do implementation testing of Foo? It's not an unreasonable >... -- Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/
signature.asc
Description: OpenPGP digital signature
