On 3/23/16, 7:01 AM, Stephen Colebourne wrote:
On 23 March 2016 at 07:21, Alan Bateman<alan.bate...@oracle.com> wrote:
If they are in the same class loader and package as
the code they are testing (the norm in Maven) then they need to compiled as
if they are part of the module.
We have worked through this white/black box testing classes in JavaFX, While
not a perfect solution we have something that seems to work (at least we get
the tests to pass anyway :-)
I created a OpenJFX Unit test in Jigsaw TOI in our wiki here
<https://wiki.openjdk.java.net/display/OpenJFX/OpenJFX+unit+tests>. While it is
specific to the JFX build, there is a lot of detail in there that is general to unit
testing and Jigsaw.
There are several keys here.
1) separate out the white/black box test classes, creating new "shims" (white box
classes) as needed. We picked the "test.*" package for the black box tests and refactored
all of our unit tests into it.
2) at build time create a copy of our "core" classes with the white box shims
added in so that we have one module override tree
3) use Xpatch, @addExports so that things can be found
"@addExport" is an argfile usage which makes adding multiline -XaddExport:
options reasonable. If you don't know about @argfile, you might want to look at my wiki
page just to learn about those :-)
Certainly the solution we have took a lot of rework, and we did debate with the
Jigsaw team about several elements of it. But what we ended up with works
within the current boundaries.
BTW - any feedback or questions on the TOI would be appreciated.
https://wiki.openjdk.java.net/display/OpenJFX/OpenJFX+unit+tests
I struggle with that idea.
To me, tests are very definitely not part of the module. To me, they
are very clearly a separate module, one that uses the base module
(separate tree of code, separate dependencies, separate compilation
phase). In maven, there is even the possibility for one testing module
to depend on another testing module, a very useful feature.
The only special case about testing modules is that they are given
full access to everything in the underlying module. Forcing test code
to be embedded within the actual module just because the module design
doesn't allow any other option is flawed IMO.
Peter Levart's mail suggested one approach to provide the necessary
access rights for testing modules. But it still requires publication
package-by-package. Really, what is needed is a way to express that
the testing module is intimately connected, perhaps imposing a
requirement that both are loaded in the same classloader. eg.
module my.mod {
fully-exposed-to my.mod.test;
}
module my.mod.test {
requires my.mod; // since other end specifies fully-exposed-to,
this gets full access
requires junit;
}
Is this issue on the list of open issues?
http://openjdk.java.net/projects/jigsaw/spec/issues/
Stephen
--
David Hill<david.h...@oracle.com>
Java Embedded Development
"A man's feet should be planted in his country, but his eyes should survey the
world."
-- George Santayana (1863 - 1952)
