After sending this mail, the more I think of it, I am not too sure
introducing a new task (junitlauncher) is serving any useful purpose. Of
course it does allow me to keep the task implementation simpler without
using the existing JUnitTask as an entry point of the call. But that is
an internal implementation detail, now that I think of it. So perhaps
just using the existing <junit> task and introducing relevant
attribute(s) to support this JUnit 5 launcher might be a better idea.
Even if we do stop supporting non-launcher based approach in some
distant future, we could still do that just by changing the internal
implementation detail of this task (and maybe removing support for
certain attributes).
Either way, I would still like to hear others thoughts on this.
-Jaikiran
On 14/12/17 3:39 PM, Jaikiran Pai wrote:
I've started some experiments in adding support for the recently
released JUnit5 [1] in Ant. I don't mean using JUnit5 for test cases
written within our Ant project, instead I am talking about allowing
users to use a Ant task to be able to run JUnit5 based test cases as
requested here [2].
Before I get into the details of what I have tried so far, I would
like to quickly explain what JUnit5 brings for us (build tool
developers). As they note in their documentation, JUnit 5 has
introduced proper APIs targetted towards build tools and IDEs to be
able to launch tests, in a simple way. Furthermore, they have
separated out these APIs from the core of the tests itself. What that
means is, the JUnit platform launcher APIs, allow build tools to
launch the JUnit platform and then once launched, the ability to
"identify" tests that need to be run depends on the plugged in engine,
which is/can be controlled by the user's environment. So essentially
the launched platform can be used to run JUnit 5 test cases (written
using JUnit 5 test APIs) or can be used to run JUnit 4 test cases
(they call these vintage). This decision is done by a pluggable test
engine, typically placed within the classpath.
With that context, I would like to explain what I have attempted so
far and I would like inputs on whether I should follow this path
and/or if there are other suggestions on how we should go ahead. As
you are probably aware, the JUnitTask (the Ant task backing the
<junit> element) has very complex logic which deals with launching the
test runners responsible for running JUnit tests (3.x or 4.x). IMO,
most this logic can now be handed off to the JUnit 5 platform
launcher, using their APIs.
So one way to add JUnit 5 support would probably be to introduce a new
attribtue on the <junit> task, something like "use-junit-launcher"
which when set, will let us rely on this JUnit 5 launcher APIs. Of
course, we would also document that the usage of this attribute would
imply that they will have to setup their library dependencies to
include all relevant JUnit 5 related jars that provide this support,
plus the relevant JUnit test engine that suits their needs. This will
allow them to use the existing <junit> task and just add a new
attribtue to deal with JUnit5.
The other approach is to introduce a new task (say <junitlauncher>)
which has the exact same support in terms of what attributes and
nested elements are supported but its implementation is completely
going to rely on the JUnit 5 platform launcher to deal with the test
execution. Practically, that means, all the existing complex code in
JUnitTask need no longer be used with this task and instead it will be
a much simpler implementation. Users who want "pure" junit 3.x or 4.x
can still stick to <junit> task, whereas users who want to use JUnit 5
based platform, either to run JUnit 4.x or 5.x can use this newer
<junitlauncher> task. Over time, in some release, we might probably
just advertise <junitlauncher> and deprecate <junit> (that's a long
way away of course, if we do indeed do that)
In my experiment, I have implemented the latter approach to show its
usage. The code/commit resides here [3]. It by no means is complete,
but does currently support JUnit 5 (and JUnit 4) in its current form.
Before I actually spend more time on this approach, I would like
inputs and thoughts on it. The usage of this task would be something
like this (just a snippet from my experimental build.xml):
<target name="test" depends="compile-tests">
<junitlauncher>
<!-- Multiple tests contained in the build.classes.dir-->
<batchtest>
<fileset dir="${build.classes.dir}"/>
</batchtest>
<!-- A specific test -->
<test name="org.myapp.FooTest"/>
<!-- classpath to be used for the tests -->
<classpath refid="test.classpath" />
</junitlauncher>
</target>
[1] http://junit.org/junit5/
[2] https://bz.apache.org/bugzilla/show_bug.cgi?id=61796
[3]
https://github.com/jaikiran/ant/commit/42c7f221a8cd0848df0a2d6cac2897c07d446bda
-Jaikiran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
