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/
|