Hi Tomas
what you describe reminds me of the way you write unit tests in .NET -
where you'd use "public" for the stuff that is exported in modules and
"internal" for things that you need inside your assembly (module) buto
don't want to provide as API.
Blackbox and Whitebox testing are common there, but you also have a way
to put your tests into a separate assembly and declare this assembly a
friend that has access to all "internal" APIs. This is the approach I've
preferred back when I was doing more .NET. IIUC this could be achived
with -XaddExports in Java9.
Needing special precautions to make JUnit see you tests really adds an
extra layer of complexity.
One thing you may have overlooked is that Ant doesn't use any built-in
JUnit runner but one of its own. And that there is an option to run the
tests inside the same VM that is currently running (fork=false, which
is the default).
AFAIU non-forked execution would only work for classpath mode. Period.
For blackbox testing you'd also have to add -addmods for the jar
containing Ant's junit runner - which isn't even inside a module and
can't be unless we repackage it for Java9. In this case we'll likely
need the approach you outlined for keeping junit on the CLASSPATH.
On 2016-04-01, Tomas Zezula wrote:
> The JUnit task needs to be extended to support all three scenarios.
> There are two possibilities how to extend the JUnitTask:
> 1st) Minimal needed changes
> Just add a modulepath to JUnit task. When junit library is not found
> on the classpath but found on the module path do the modular execution
> by -m junit/<mainclz> rather than classpath execution. The user is
> responsible for passing the -XPatch, -XaddExports, -XaddReads,
> -addmods JVM options. Options like -XaddExports are harder to
> calculate as they require list of test packages. But it can be done by
> the following pathconvert:
> <dirset id="packages" dir="build/test/classes" includes="*"/>
> <pathconvert refid="packages" property=“exports.cmd” pathsep=" ">
> <chainedmapper>
> <flattenmapper/>
> <globmapper from="*" to="-XaddExports:${module.name}/*=junit"/>
> </chainedmapper>
> </pathconvert>
Sounds good but likely needs to extend to ant-junit?.jar as well.
> 2nd) Extend Junit task to automatically set the -XPatch, -XaddExports,
> -XaddReads, -addmods options for modular execution.
> This will require adding more attributes to JUnit task (path to test
> classes to do the -XPatch, ability to disable the automatic options).
And detect whether module support is available at all. In addition the
VM that is forked may be a different one from the one currently
running. We could be forking a Java9 VM even if Ant was running in a
Java8 VM and vice versa. I'd suggest to add an explicit flag users must
enable before trying to add any magic.
Cheers
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
