ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jaikiran Pai <>
Subject Ant support for users who use JUnit5
Date Thu, 14 Dec 2017 10:09:26 GMT
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">
             <!-- Multiple tests contained in the build.classes.dir-->
               <fileset dir="${build.classes.dir}"/>
             <!-- A specific test -->
             <test name="org.myapp.FooTest"/>
             <!-- classpath to be used for the tests -->
             <classpath refid="test.classpath" />



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message