Etienne Gagnon wrote:
Just a random idea... Why not have a special "testing" mode in the VM
that would trigger special permissions to code in ".test" packages?
You wouldn't need that when testing in the VM. :)
That's why Tim suggested o.a.h.test.xxxx so then you stay out of package
namespace that "belongs" to the boot classpath.
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.
To me the problem then is that our VM becomes a testing framework - why
not just have a testing framework?
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. ;-)
Not a bad one, but it seems like a special "testing framework" with just
another name :)
geir
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
...
